Non-static websites have a web-server which often receives user-input and then queries other server-tools: databases, search-indexes, queues. The act of user-input triggering reads and writes to server-tools creates vectors for serious vulnerabilities.
Static-sites still (usually) have a web-server -- but because all the web-server does is directly serve out simple files -- whole categories of serious vulnerabilities are eliminated.
But security-vulnerabilities can still exit in static-sites.
From the research-scan I've done, there are two main categories to be aware of:
- the context in which the static-site is served
- javascript vulnerabilites
- Have the web-server configured to only serve out content via https vs http improves the ability for users to access site-data confidentially.
- Have the web-server configured to send certain http-headers can mitigate risk of some javascript vulnerabilities. Examples:
X-Frame-Options: SAMEORIGIN(minimizes iframe-based cross-site-scripting attacks)X-XSS-Protection: 1; mode=block(minimizes iframe-based cross-site-scripting attacks)X-Content-Type-Options: nosniff(disables browser guessing the file-format)Content-Type: text/html; charset=utf-8(indirectly improves security by ensuring proper interpretation of content, minimizes encoding-obfuscation)
Most javascript vulnerabilities lead to allowing Cross-Site Scripting (XSS) attacks. This is a situation in which an attacker figures out a way to inject malicious javascript into your website, and have your browser run it, for nefarious purposes. Example, the malicious javascript could, upon you attempting to load a supposedly public-page, put up a form requesting you to log in with your google credentials, to steal them.
- Load javascript libraries from your own web-server or trusted CDNs -- to minimize the risk of the javascript-package getting hacked.
- Run js-packages through a checker like Snyk Vulnerability Database or retire.js to check for vulnerabilities -- especially if they're in any way related to user-input.
- Be sure that your git repo is not accessible in your static-directory. You may have a a past version of something that yields credentials or server-information you wouldn't want shared.
- Like javascript, load other files, especially images, locally. Folk have crafted malicious svg files that facilitate cross-site-scripting.
-
example-search for vulnerable npm xml packages: https://security.snyk.io/vuln/npm?search=xml
-
example-search for vulnerabile npm search packages: https://security.snyk.io/vuln/npm?search=search
-
ChatGPT questions (info should always be verified)
- "can static-site-generated websites still have security vulnerabilities?": https://chat.openai.com/chat/2e3fd98c-616a-483b-8099-4156119c2cf4
- http-header & cross-site-scripting questions: https://chat.openai.com/share/b4eaf4df-b736-407b-9115-1b177c722e3e
- general question about Prototype-Pollution -- a common javascript-vulnerability: https://chat.openai.com/share/bb4f8c32-3ebd-4241-b3a7-0cbcaf2c0d85
(end)