Here are a few commonly seen HTTP security features.
Content Security Policy (CSP)
Content Security Policy (CSP) is an added layer of security that helps to detect and mitigate Cross-Site Scripting (XSS) and data injection attacks.
To enable CSP, you need to configure your web server to return the Content-Security-Policy HTTP header. If the site doesn't offer the CSP header, browsers likewise use the standard same-origin policy.
CSP makes it possible for server administrators to reduce or eliminate the vectors by which XSS can occur by specifying the domains that the browser should consider to be valid sources of executable scripts. A CSP compatible browser will then only execute scripts loaded in source files received from those allowed domains, ignoring all other scripts (including inline scripts and event-handling HTML attributes).
Examples:
Content-Security-Policy: default-src 'self'
Content-Security-Policy: default-src 'self' example.com *.example.com
Content-Security-Policy: default-src 'self'; img-src *; media-src example.org example.net; script-src userscripts.example.com
Content-Security-Policy: default-src https://onlinebanking.example.com
Content-Security-Policy: default-src 'self' *.example.com; img-src *
Content-Security-Policy: default-src 'self'; report-uri http://reportcollector.example.com/collector.cgi
Using HTTP cookies
An HTTP cookie is a small piece of data that a server sends to a user's web browser. The browser may store the cookie and send it back to the same server with later requests. Typically, an HTTP cookie is used to tell if two requests come from the same browser—keeping a user logged in.
Cookies are mainly used for three purposes: Session management, User preferences, and Tracking.
Instead of using cookies, modern APIs for client storage are the Web Storage API (localStorage and sessionStorage) and IndexedDB.
Example (set cookies) on sending cookie to client browser.
Set-Cookie: yummy_cookie=choco
Set-Cookie: tasty_cookie=strawberry
Set-Cookie: id=a3fWa; Expires=Thu, 31 Oct 2021 07:28:00 GMT;
Set-Cookie: id=a3fWa; Expires=Thu, 21 Oct 2021 07:28:00 GMT; Secure; HttpOnly
Set-Cookie: mykey=myvalue; SameSite=Strict
Example () on sending stored cookies to web server.
Cookie: yummy_cookie=choco; tasty_cookie=strawberry
Additional ways to mitigate attacjs involving cookies:
- Use the HttpOnly attribute to prevent access to cookie values via JavaScript.
- Use the Secure attribute to prevent MiTM attack and ensure its never sent with unsecured HTTP.
- Use short lifetime, with SameSite attributes to protect sensitive info.
Same-origin policy (web security)
The same-origin policy is a critical security mechanism that restricts how a document or script loaded by one origin can interact with a resource from another origin. It helps isolate potentially malicious documents, reducing possible attack vectors.
"Same origin" means the protocol, port (if specified), and host are the same for both. It is referenced as the "scheme/host/port tuple".
For example, an URL at http://store.company.com/dir/page.html will give origin comparison as below:
| URL | Reason | Outcome |
|---|---|---|
| http://store.company.com/dir2/other.html | Only the path differs | Same origin |
| http://store.company.com/dir/inner/another.html | Only the path differs | Same origin |
| https://store.company.com/page.html | Protocol different | Fail |
| http://store.company.com:81/dir/page.html | Port different | Fail |
| http://news.company.com/dir/page.html | Host different | Fail |
Other schemes or URL, such as javascript: and about:blank, are inherited origins from the page. But data: scheme get a new security context. file:/// schema is treated as opaque origins.
Use CORS to allow cross-origin access. CORS is a part of HTTP that lets servers specify any other hosts from which a browser should permit loading of content.
Strict-Transport-Security (HTTP header)
The HSTS or HTTP Strict-Transport-Security response header informs browsers that the site should only be accessed using HTTPS, and that any future attempts to access it using HTTP should automatically be converted to HTTPS.
This is more secure than simply configuring a HTTP to HTTPS (301) redirect on your server, where the initial HTTP connection is still vulnerable to a man-in-the-middle attack.
Example of all the present and future subdomains will be HTTPS for a max-age of 1 year:
Strict-Transport-Security: max-age=31536000; includeSubDomains
Strict-Transport-Security: max-age=31536000; preload
Strict-Transport-Security: max-age=63072000; includeSubDomains; preload
To detect if a HTTPS server is supporting HSTS, check the post at When HTTPS is not Sufficient.
X-Content-Type-Options (HTTP header)
This is a web server HTTP header to indicate that the MIME types advertised in the Content-Type headers should be followed and not be changed. The header allows you to avoid MIME type sniffing by saying that the MIME types are deliberately configured.
For example, it can cause HTML web pages to be downloaded instead of being rendered when they are served with a MIME type other than text/html.
Site security testers usually expect this header to be set, such as:
X-Content-Type-Options: nosniff
X-Frame-Options (HTTP header)
This is a web server response header to indicate whether or not a browser should be allowed to render a page in a <frame>, <iframe>, <embed> or <object>. Sites can use this to avoid click-jacking attacks, by ensuring that their content is not embedded into other sites.
The Content-Security-Policy HTTP header has a frame-ancestors directive which obsoletes this header for supporting browsers.
X-Frame-Options: DENY
X-Frame-Options: SAMEORIGIN
If you specify DENY, the page cannot be displayed in a frame, regardless of the site attempting to do so.
If you specify SAMEORIGIN, the page can only be displayed if all ancestor frames are same origin to the page itself.
X-XSS-Protection (HTTP header)
This is a server response header sent to browser that stops pages from loading when they detect reflected cross-site scripting (XSS) attacks. These protection is unnecessary when sites implement a strong Content-Security-Policy that disables the use of inline JavaScript ('unsafe-inline').
This feature is not a standard feature for all browsers. Do not use it on production sites facing the Web: it will not work for every user. There may also be large incompatibilities between implementations and the behavior may change in the future.
Directives:
X-XSS-Protection: 0
X-XSS-Protection: 1
X-XSS-Protection: 1; mode=block
X-XSS-Protection: 1; report=<reporting-uri>
Examples:
X-XSS-Protection: 1; mode=block
Apache (.htaccess):
<IfModule mod_headers.c>
Header set X-XSS-Protection "1; mode=block"
</IfModule>
Nginx:
add_header "X-XSS-Protection" "1; mode=block";
Links:
- Content Security Policy (CSP)
- Using HTTP cookies
- Same-origin policy (web security)
- Strict-Transport-Security (HTTP header)
- X-Content-Type-Options (HTTP header)
- X-Frame-Options (HTTP header)
- X-XSS-Protection (HTTP header)
- HTTP Request Methods
