In this blog post, we will explore the vulnerabilities associated with insecure HTTP server response headers, discuss the potential impact on web applications, and provide examples relating to creating secure header configurations. The following headers are covered:
- HTTP Strict Transport Security
- Content-Security Policy
- Cache-Control
- X-frame options
- X-Content-Type options
- Subresource integrity
- Access-control allow origin
Web servers communicate with browsers through HTTP response headers, providing instructions on how to handle the displayed content. Insecure configurations or the absence of specific security headers can expose web applications to various risks.
HTTP Strict Transport Security (HSTS)
HTTP Strict Transport Security (HSTS) is a web security policy mechanism that helps to protect websites against man-in-the-middle attacks such as protocol downgrade attacks and cookie hijacking. HSTS allows a website to declare to browsers that it should only be accessed using secure, encrypted connections, typically over HTTPS (HTTP Secure).
When a web server sends the HSTS header to the browser, it instructs the browser to only connect to the specified domain over HTTPS for a specified period. During this period, the browser will automatically convert any HTTP links or requests to HTTPS before sending them. This helps to enforce a secure connection and reduces the risk of users accidentally accessing the site over an insecure connection.
|
1 |
Strict-Transport-Security: max-age=31536000; includeSubDomains; preload; |
Here are the primary directives that can be set in the HSTS header:
max-age
Specifies the time, in seconds, that the browser should remember to enforce HSTS. In the example above, it’s set to 31,536,000 seconds, which is one year.
includeSubDomains
Optional directive that indicates that the HSTS policy should also be applied to all subdomains of the specified domain.
preload
Optional directive that indicates that the domain should be included in the HSTS preload list. Being on the preload list means that browsers will automatically enforce HSTS for the domain, even for the first visit.
It’s important to note that once a browser has received and processed the HSTS header, it will automatically redirect any HTTP requests to HTTPS for the specified domain and its subdomains. This can have implications during the initial implementation, so careful testing is recommended. If the application relies on clear-text HTTP requests and the HSTS flag is implemented, this will break the application.
Additionally, the preload directive is part of the HSTS preload mechanism, which involves submitting your domain to be included in a list of HSTS-enabled sites that are hardcoded into major web browsers. This can be done at the HSTS Preload website.
When implementing HSTS, it’s crucial to ensure that your website is already serving securely over HTTPS and that you understand the potential impact on users who may have bookmarks or old links using HTTP. Testing in a controlled environment is highly recommended before deploying HSTS in a production setting.
How to implement HTTP Strict Transport Security Header (HSTS)
Nginx
Use the add_header directive. The add_header directive is used to add, replace, or clear response headers.
To find the header block in NGINX for updating server response headers, you’ll typically look within the server block of your NGINX configuration file. The location of this file may vary depending on your system, but common locations include /etc/nginx/nginx.conf or a directory like /etc/nginx/conf.d/.
Add the following data to the header block:
|
1 2 3 4 5 |
server { add_header Strict-Transport-Security "max-age=31536000; includeSubDomains; preload" always; } |
Apache
Update server response headers using the Header directive. The location of the Apache configuration file can vary depending on your system, but common locations include /etc/httpd/httpd.conf or /etc/apache2/apache2.conf. Additionally, Apache allows per-directory configuration through .htaccess files.
|
1 2 3 4 5 |
<IfModule mod_headers.c> Header always set Strict-Transport-Security "max-age=31536000; includeSubDomains; preload" </IfModule> |
Microsoft IIS
Select your Site: In the Connections pane on the left side, navigate to your site (or the site you want to apply HSTS to).
In the middle pane, double-click on the “HTTP Response Headers” icon.
In the Actions pane on the right side, click on “Add…”.
Set HSTS Header Values: Enter the following values:
- Name: Strict-Transport-Security
- Value: max-age=31536000; includeSubDomains; preload
This example sets the HSTS policy for 1 year (31536000 seconds), includes subdomains (includeSubDomains), and indicates that the site should be included in the HSTS preload list (preload).
Save Configuration: After adding the header, click on “OK” to save the configuration.
Restart IIS: For the changes to take effect, you may need to restart IIS. You can do this by clicking on the server name in the Connections pane, then clicking on “Restart” in the Actions pane on the right.
Content Security Policy (CSP)
The Content Security Policy (CSP) is a web security standard that helps protect against various types of attacks, including Cross-Site Scripting (XSS) and data injection attacks. CSP works by allowing web developers to declare the sources from which a browser should consider executing or loading resources. This is done through declaring directives within the header. There are many directives; however, each directive shares the same options that can be associated with it. (i.e – none, self, unsafe-inline).
Implementing the CSP
Implementing a CSP requires more research than the other headers mentioned in this article as an incorrect implementation could stop the application from working correctly and not all applications require the same directives as these are functionality dependent. There are various 3rd party tools including browser extensions and websites that generate these policies. It is important to test your application after implementing a Content Security Policy. There are several features within CSP that allow testing, such as report-to (and/or using the Content-Security-Policy-Report-Only header), and report-sample.
The report-to feature allows the developer to set an endpoint to report any violations of the Content Security Policy. This is helpful for logging and investigating any malicious attacks.
The Content-Security-Policy-Report-Only header does not prevent any violations of policy but it reports them to a specified endpoint. This is useful for debugging and testing policy.
A permissive CSP is likely much stronger than no CSP, although they can often be bypassed. For example, if a source that hosts content vulnerable to XSS is used, or it is a source that anyone can upload to, such as S3 (http://s3.amazonaws.com), anyone can upload a file that may bypass these protections. CSP evaluators exist, such as https://csp-evaluator.withgoogle.com/, which will help identify these weaknesses.
Default-src directive
The default-src directive is used to control the sources from which scripts can be executed. This is the first directive to consider. The following options can be used with all other directives but the impact differs depending on which directive the option is associated with.
None
It is also possible to set the CSP to not allow any external resources at all by declaring the default-src. If you use default-src ‘none’;, the browser will block the loading of all external resources, including scripts, stylesheets, images, fonts, and other types of assets, even if they are hosted on the same domain as the web page. This level of strictness can have a significant impact on the functionality and appearance of your web application, so it should be used with caution.
|
1 |
Content-Security-Policy: default-src 'none'; |
Self
If your application does not require any external resources, you could consider implementing a CSP with the directive default-src ‘self’. This policy restricts the loading of content such as scripts, styles, images, fonts and other resources to only those that are hosted on the same domain as the application. If you are certain that your application does not rely on external resources then this can be implemented safely; however, you should test your application after to make sure you didn’t overlook any external resources
|
1 |
Content-Security-Policy: default-src 'self'; |
Setting the default-src to self sets all other options that have not been explicitly set to something else to self as well.
The above content security policy could be used as a valid configuration for the following webpage. This example shows the webpage loading an external resource that is hosted on the same domain.
|
1 2 3 4 5 6 7 8 9 10 11 |
<body> <h1>Welcome to My Website</h1> <script src="script.js"></script> <img src="images/logo.png" alt="Logo"> </body> </html> |
Allow from a specific domain
If your application does require resources from an external host, then the default-src policy can also be used to specify an external host that your application will accept resources from. The following example still uses the self option, allowing resources from the same domain, but it also allows resources from the domain ‘csp.trustfoundry.net’.
|
1 |
Content-Security-Policy: default-src 'self' https://csp.trustfoundry.net; |
Allow a domain and all of its subdomains using a wildcard (*)
It is possible to use wildcard values to allow a specific domain and all of its subdomains. In the following example, a.trustfoundry.net, b.trustfoundry.net or any subdomains of trustfoundry.net can share resources with the application.
|
1 |
Content-Security-Policy: default-src 'self' https://*.trustfoundry.net; |
Allow all domains using a wildcard (*)
Allowing all domains is not recommended and ultimately defeats the purpose of the CSP. This will come with security risks such as cross-site scripting and data exfiltration.
|
1 |
Content-Security-Policy: default-src *; |
Unsafe-inline
unsafe-inline allows the execution of inline scripts. An inline script is a script that is included directly in the source code of a page, whereas an external resource is a script that is hosted on another page and directly linked to the document. Implementing this option will allow malicious threat actors to inject malicious JavaScript into your application that could execute, assuming the parameters are not sanitized. If the CSP is set to not allow inline scripts, even if the parameters are not sanitized, this will prevent the execution of the cross-site scripting attack.
|
1 |
Content-Security-Policy: default-src 'unsafe-inline' |
An example of where it may be necessary to use the unsafe-inline option is a web application that dynamically generates HTML content, and part of this content includes inline event handlers, such as onclick attributes. In some cases, you might need to dynamically attach event handlers directly in the HTML markup.
|
1 2 3 4 5 6 7 8 9 10 11 12 13 |
<head> <title>Example Using 'unsafe-inline'</title> <meta http-equiv="Content-Security-Policy" content="default-src 'self'; script-src 'unsafe-inline'"> </head> <body> <strong><button onclick="alert('Hello, World!')">Click me</button></strong> </body> |
Unsafe-Eval
Unsafe-eval allows the execution of code that is generated dynamically at runtime using functions like eval(), new Function(), and similar methods. It is not recommended due to the risk of cross-site scripting attacks, similar to unsafe-inline. An example of where it may be necessary to use unsafe-eval is if you are using the eval() function inline within the document.
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 |
<head> <title>Example Using 'unsafe-eval'</title> <meta http-equiv="Content-Security-Policy" content="default-src 'self'; script-src 'unsafe-eval';"> </head> <body> <script> // This script uses eval, which would be allowed with 'unsafe-eval' var x = 5; var y = 10; var result = eval('x + y'); console.log(result); // Outputs 15 </script> |
Strict-dynamic
Strict-dynamic can be used in the default-src , script-src and other directives but it is only advised to use it in the script-src directive. The strict-dynamic value allows the execution of inline and dynamically created scripts from whitelisted sources. Take the following example:
|
1 2 |
Content-Security-Policy "default-src 'self'; script-src 'strict-dynamic' <strong>'nonce- randomlygeneratednonce'</strong> |
The strict-dynamic option has been set with a nonce (number used once); this nonce will need to be attached to any inline or dynamic code for it to be executed. This involves generating a unique nonce for each page load and adding it to the CSP header and the corresponding script tags. This adds an extra layer of security by allowing only scripts with the matching nonce to execute. For example:
|
1 2 3 4 5 6 7 8 9 |
<!-- Inline script with nonce --> <script nonce="randomlygeneratednonce"> // This inline script will be allowed due to the nonce console.log('Hello, World!'); </script> |
SHA-256 Hash
When you include SHA-256 hashes in the default-src directive, you are specifying the allowed sources by providing a cryptographic hash of the content. This hash is calculated based on the actual content of the resource. This means that only resources with content that matches the specified hash will be allowed to load. This mitigates the risk of a malicious threat actor modifying the contents of a JavaScript file to attack the application as if the contents do not match the hash, the file will not be executed.
This directive is more commonly used in script-src.
|
1 |
Content-Security-Policy: default-src 'self' 'sha256-ABC123...'; |
Report-sample
Report-sample can be used to trigger debugging reports for content-security-policy violations.
Content-Security-Policy: default-src ‘self’ ‘report-sample’;
This example shows a developer trying to load an inline resource with the report-sample option enabled.
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 |
<body> <h1>Hello, World!</h1> <!-- Inline script that will trigger a violation --> <script> // This inline script will trigger a CSP violation alert('Hello, World!'); </script> The violation report would look something like this: { "csp-report": { "document-uri": "https://example.com/page.html", "referrer": "", "violated-directive": "default-src 'self' 'report-sample'", "blocked-uri": "inline", "original-policy": "default-src 'self' 'report-sample'", "script-sample": "alert('Hello, World!');", "line-number": 5, "source-file": "https://example.com/page.html" } } |
Script-src directive
It is important to note that the majority of the above options for default-src apply to script-src and all other directives. A pattern is followed but they typically do something slightly different, depending on the directive the option is associated with. Listed below are the possible options for a directive as well as their different uses for the default-src and script-src directives.
none
In both default-src and script-src, ‘none’ means that no external resources or scripts are allowed, providing a strict policy.
|
1 |
Content-Security-Policy: script-src 'none' |
self
In default-src, ‘self’ allows content from the same origin as the document for all types of resources, including scripts. In script-src, ‘self’ specifically allows scripts to be loaded only from the same origin.
|
1 |
Content-Security-Policy: script-src 'self' |
Allow from a specific domain
In default-src, allowing a specific domain sets all undeclared directives to allow resources from the allowed domain. In script-src, it only allows scripts from the domain, not images, fonts, etc.
|
1 |
Content-Security-Policy: script-src 'self' https://csp.trustfoundry.net; |
Allow a domain and all of its subdomains using a wildcard (*)
In default-src, allowing a specific domain and subdomains sets the undeclared directives to allow resources from the domain and subdomains. In script-src, it will only allow scripts from these domains.
|
1 |
Content-Security-Policy: script-src 'self' https://*.trustfoundry.net; |
Allow all domains using a wildcard (*)
In default-src, allowing all domains sets all undeclared directives to the wildcard value. In script-src, it only allows scripts from all sources, not images, fonts, etc.
|
1 |
Content-Security-Policy: script-src *; |
unsafe-inline
In default-src, ‘unsafe-inline’ allows the use of inline scripts and styles in the HTML document. In script-src, ‘unsafe-inline’ allows the execution of inline scripts.
|
1 |
Content-Security-Policy: script-src 'unsafe-inline' |
unsafe-eval
When you include unsafe-eval in the default-src directive, it means that any inline scripts or styles embedded directly within your HTML document will be allowed to execute. When you include unsafe-eval in the script-src directive, it specifically applies to scripts. It allows the execution of inline scripts but only for the script-src policy.
|
1 |
Content-Security-Policy: script-src 'self' unsafe-eval; |
strict-dynamic
When you include strict-dynamic in the default-src directive, it allows the execution of inline scripts but only if they are generated by trusted scripts (scripts that are whitelisted in your CSP policy). When you include This means that strict-dynamic can apply to all resources but scrirpt-src can only apply to JavaScript files.
|
1 |
Content-Security-Policy: script-src 'self' strict-dynamic; |
SHA-256
It is also possible to use a SHA256 hash to verify that a script only contains the expected contents. Using a sha256-value in script-src can be a security measure when you have specific scripts that need to be executed inline, and you want to ensure their integrity.
|
1 2 |
Content-Security-Policy default-src 'self'; script-src 'sha256-K8SuvrgaTg+SoLIFCz6O3+/hHjxT1+hQ OckAH6b+5xE=' |
The following inline script will only execute if it matches the SHA-256 hash.
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 |
<title>CSP Example with 'sha256-value'</title> <meta http-equiv="Content-Security-Policy" content="default-src 'self'; script-src 'sha256-K8SuvrgaTg+SoLIFCz6O3+/hHjxT1+hQOckAH6b+5xE=';"> </head> <body> <!-- Inline script with the specified SHA-256 hash --> <script> // This inline script will only be allowed if its hash matches the specified value console.log('Hello, World!'); </script> |
How to implement the CSP
Nginx
Open the Nginx configuration file for your website or application. This file is typically located in the /etc/nginx/sites-available/ directory. The main configuration file may be named nginx.conf or default depending on your setup. Inside the server block, use the add-header directive.
|
1 2 3 4 5 6 7 8 9 |
server { # ... other server configurations ... add_header Content-Security-Policy "default-src 'self'; script-src 'self' 'unsafe-inline'; style-src 'self'"; # ... other server configurations ... } |
Apache
For Apache, the configuration is typically located in the /etc/apache2/ directory. The main configuration file is usually named httpd.conf, and additional configuration files may be included from the conf-enabled/ or sites-enabled/ directory.
Main Configuration File:
/etc/apache2/httpd.conf
Additional Configuration Files:
/etc/apache2/conf-enabled/
/etc/apache2/sites-enabled/
You can add the cache control directives in a <Directory> block or within a specific <VirtualHost> configuration.
|
1 2 3 4 5 |
<IfModule mod_headers.c> Header set Content-Security-Policy "default-src 'self'; script-src 'self' 'unsafe-inline'; style-src 'self'" </IfModule> |
Other directives
There are many other directives that have not been covered, however, we have covered some of the most crucial ones. If you would like to learn more about other directives, please visit the Firefox documentation. Some more examples have been covered below.
https://developer.mozilla.org/en-US/docs/Web/HTTP/CSP
frame-src
This directive controls the sources from which the browser is allowed to load and embed frames on the current page.
frame-ancestors
This directive controls which sources are allowed to embed a web page using an <iframe>, <frame>, <object>, or <embed> tag. This can be used to reduce the risk of clickjacking attacks. Setting this option to self will only allow iframes from the same domain, or the directive can be set to allow a specific domain. If this header has not been set and the application also does not use the X-Frame-Options header, the site is likely vulnerable to clickjacking.
style-src
This directive controls the sources from which stylesheets can be applied. The same options apply to the style-src directive as the directives above. Typically, this will be set to self, unless external resources are required.
connect-src
This directive defines the allowed sources to which the browser can make network requests, such as fetching resources through XMLHttpRequest, Fetch API, WebSocket connections, and other similar mechanisms. This directive helps in preventing malicious connections to unauthorized or potentially harmful domains.
font-src
This directive is used to control the sources from which the browser can fetch and apply fonts on a web page. This directive helps mitigate certain types of attacks, such as font-based exploits.
object-src
This directive is used to control the sources from which the browser is allowed to load embedded objects, such as Flash, Java applets, or other plugins.
media-src
This directive is used to control the sources from which the browser is allowed to load audio and video content.
img-src
This directive is used to control the sources from which a browser is allowed to load image resources.
form-action
This directive is used to control the sources to which the browser is allowed to submit forms.
base-uri
This directive specifies the base URI for resolving relative URLs. One should be cautious with setting overly permissive values, as it can affect the base URL for all kinds of resources, potentially leading to security issues if not properly restricted. For example, an overly permissive base-uri could lead to an attacker injecting or loading content from unauthorized sources. It may also lead to data exfiltration, content injection, clickjacking and content spoofing.
child-src
This directive restricts the URLs that can be loaded as a worker or imported into a script via <iframe>, <frame>, <object>, <embed>, or similar elements. Use it to prevent the loading of untrusted content into frames or iframes. Be careful with allowing potentially dangerous sources in child-src.
Child-src and frame-ancestors are both directives in a CSP that are related to controlling the embedding of content in a page, but they serve different purposes. The purpose of child-src is to specify the valid sources for content that can be loaded as a worker or imported into a script via elements like <iframe>, <frame>, <object>, <embed>, etc, whereas frame-ancestors specifies the valid sources that can embed the current page using elements like <frame>, <iframe>, <object>, <embed>, etc.
manifest-src
The manifest-src directive in a CSP is used to specify the valid sources for the web application manifest file. The web app manifest is a JSON file that provides metadata about a web application, such as its name, description, icons, and other properties. This manifest file is used by browsers and other platforms to provide a more “app-like” experience for users. By specifying valid sources for the web app manifest, the manifest-src directive helps ensure that the manifest file is loaded only from trusted locations. This can prevent tampering with the manifest file, which might impact how the web application is presented to users.
report-to
As of December 2023, this is not currently supported by Firefox, so report-uri should also be used.
Sandbox
The sandbox attribute is used in HTML to create a sandboxed environment for the execution of an embedded frame (e.g., an <iframe>). It’s a security feature that restricts certain behaviors of the embedded content, helping to mitigate potential security risks and protect the surrounding web page.
When the sandbox attribute is applied to an <iframe>, it creates a restricted execution environment for the content within that frame. The attribute can take various values that specify the restrictions imposed on the embedded content.
script-src-attr
The script-src-attr directive is used to control the allowed sources for inline script event handlers, such as those specified using HTML attributes like onmouseover or onclick. It allows you to specify which domains or sources are allowed to be used as event handlers for inline scripts.
script-src-elem
The script-src-elem directive is used to control the allowed sources for inline script elements. It specifies the valid sources for scripts that are embedded directly within the HTML document using <script> tags.
style-src-attr
The style-src-attr directive is used to control the allowed sources for inline styles specified using HTML attributes like style. It allows you to specify which domains or sources are allowed to be used as inline styles in your HTML document.
style-src-elem
The style-src-elem directive is used to control the allowed sources for inline <style> elements. It specifies the valid sources for styles that are embedded directly within the HTML document using <style> tags.
upgrade-insecure-requests
The upgrade-insecure-requests directive is used to automatically upgrade HTTP requests to HTTPS. When this directive is present, the browser will attempt to upgrade any insecure (HTTP) URLs to secure (HTTPS) URLs, helping to ensure that resources are loaded securely.
navigate-to
The navigate-to directive is used to control whether a document loaded in an iframe is allowed to navigate the top-level browsing context. It helps prevent clickjacking attacks by restricting the ability of embedded content to navigate the top-level window.
Experimental
require-trusted-types-for
The require-trusted-types-for directive is used in a CSP to enforce Trusted Types for certain types of JavaScript execution. It specifies which execution contexts require Trusted Types to be enforced. Trusted Types is a browser security feature that helps prevent XSS attacks by enforcing a strong type-based security model for script execution.
trusted-types
The trusted-types directive is used to enable or disable the enforcement of Trusted Types in the context of a Content Security Policy. Trusted Types is a security standard that defines a set of policies and APIs to prevent XSS attacks by enforcing strict type checking for user inputs and dynamic code execution. The trusted-types directive enables or disables the Trusted Types policy for a given document.
Obsolete
The following directives are considered obsolete and should not be used:
- block-all-mixed-content
plugin-types - prefetch-src
- referrer
- report-uri
Cache-Control
The Cache-Control header is an HTTP header used to specify caching directives in both requests and responses. It provides a way for servers and clients to control the caching behaviour of resources. The Cache-Control header directives define how a resource can be cached, where it can be cached, and for how long. Insecure Cache-Control configurations can lead to security risks, such as client-side caching which allows a malicious threat actor to use the back button on a browser in a shared computing environment to view previously cached pages with sensitive data.
There are also some useability considerations as an incorrect configuration for your application may lead to the application not functioning correctly. Whilst each application differs the following points should be considered.
Ensure that you understand Resource Types. Different types of resources may have different caching requirements. For example, static assets (images, stylesheets) might have a longer cache duration than dynamic HTML pages.
Set the max-age appropriately to control how long browsers should cache resources. Use a balance between performance and freshness.
Use versioning or hashing when deploying changes to static resources. Using versioning or content hashing in the filenames will force browsers to download the updated resource. A strict Cache-Control policy is no-cache, no-store, must-revalidate.
The Cache-Control header has multiple directives:
public
Indicates that the response may be cached by any cache, including shared proxies.
private
Specifies that the response is specific to a single user and should not be cached by shared caches.
no-store
Directs caches not to store a copy of the response under any conditions. This is often used for sensitive data.
no-cache
Requires caches to revalidate the resource with the server before serving it from the cache. However, the resource can still be cached.
max-age
Specifies the maximum amount of time, in seconds, that the response may be considered fresh.
s-maxage
Similar to max-age but applies only to shared caches (e.g., proxy servers).
must-revalidate
Instructs caches to revalidate the resource with the server before using a cached copy, even if it is fresh.
proxy-revalidate:
Similar to must-revalidate but applies only to proxy caches.
How to implement the cache-control header
Cloudflare
Log in to Cloudflare:
Open your web browser and log in to your Cloudflare account.
Select Your Domain:
From the Cloudflare dashboard, select the domain for which you want to configure cache control.
Go to the “Caching” Section:
Navigate to the “Caching” section in the Cloudflare dashboard. The specific location may vary slightly based on the Cloudflare dashboard version.
Configure Browser Cache TTL:
Look for settings related to “Browser Cache TTL” or “Browser Cache Expiration.” This controls how long browsers should cache static assets such as images, stylesheets, and scripts.
Set an appropriate value for the browser cache TTL, considering the frequency of updates to your static assets.
Configure Edge Cache TTL:
Look for settings related to “Edge Cache TTL” or “Edge Cache Expiration.” This controls how long Cloudflare’s edge servers should cache your content.
Set an appropriate value for the edge cache TTL based on the nature of your content and update frequency.
Page Rules (Optional):
For more granular control, you can use Cloudflare Page Rules to set cache control directives for specific URLs or URL patterns.
Create a new Page Rule and define the cache control settings according to your requirements.
AWS
Open CloudFront Console:
Open the CloudFront console.
Select Distribution:
Select the CloudFront distribution for which you want to configure cache control.
Configure Cache Behavior:
Under the “Behaviors” tab, select the cache behavior you want to configure.
Adjust the caching settings, including TTL (time-to-live), query strings, and cookies, according to your requirements.
Save Changes:
Save the changes to update the cache control settings.
Invalidations (Optional):
If you need to purge specific files or paths from the CloudFront cache, you can create invalidations.
AWS Management Console
Open S3 Console:
Open the Amazon S3 console.
Select Bucket:
Select the S3 bucket where your content is stored.
Upload Object with Cache-Control Headers:
When uploading or updating objects, set the Cache-Control headers.
For example, set the Cache-Control metadata key with a value like max-age=3600 to indicate a one-hour cache duration.
Amazon API Gateway:
Log in to AWS Console:
Log in to the AWS Management Console.
Open API Gateway Console:
Open the Amazon API Gateway console.
Select API:
Select the API for which you want to configure caching.
Configure Caching:
Under the “Stages” section, select the desired stage.
Enable caching and configure settings such as cache capacity and TTL.
Deploy API:
Deploy the API to apply the caching settings.
NGINX
The NGINX configuration is typically found in one or more files in the /etc/nginx/ directory. The main configuration file is often named nginx.conf, and additional configuration files may be included from the conf.d/ directory.
Main Configuration File:
/etc/nginx/nginx.conf
Additional Configuration Files:
/etc/nginx/conf.d/
You can add the Cache-Control directives in a location block within your server configuration.
|
1 2 3 4 5 6 7 |
location /path/to/resources { add_header Cache-Control "no-cache, no-store, must-revalidate"; # Additional configuration for serving the resources } |
Apache
For Apache, the configuration is typically located in the /etc/apache2/ directory. The main configuration file is usually named httpd.conf, and additional configuration files may be included from the conf-enabled/ or sites-enabled/ directory.
Main Configuration File:
/etc/apache2/httpd.conf
Additional Configuration Files:
/etc/apache2/conf-enabled/
/etc/apache2/sites-enabled/
You can add the Cache-Control directives in a <Directory> block or within a specific <VirtualHost> configuration.
IIS
In IIS, you can set HTTP response headers through the IIS Manager or by modifying the web.config file.
Open IIS Manager
In the left Connections pane, navigate to your server node, and then click on your website or application under the “Sites” node.
Double-Click on “HTTP Response Headers”
In the Features View, find and double-click on “HTTP Response Headers.”
Add Custom HTTP Response Header
In the Actions pane on the right, click on “Add…” to add a new custom HTTP response header.
Configure the Header
Set the following values:
Name: Cache-Control
Value: no-cache, no-store, must-revalidate
This can also be done through the web.config file. Here’s an example of setting the Cache-Control header using the <staticContent> element in the web.config file:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 |
<configuration> <system.webServer> <staticContent> <clientCache cacheControlMode="UseMaxAge" cacheControlMaxAge="0" /> </staticContent> </system.webServer> </configuration> |
X-Frame-Options
It should be noted that this header has been replaced by the Frame-Ancestors CSP directive. The X-Frame-Options header is used to control whether a web page can be displayed in an <iframe>. It helps prevent clickjacking attacks by specifying which domains are allowed to embed the content. The header supports three possible directives:
DENY
This directive prevents the page from being displayed in a frame, regardless of the site attempting to do so. This prevents clickjacking attacks completely by blocking all iframes.
|
1 |
X-Frame-Options: DENY; |
SAMEORIGIN
This directive allows the page to be displayed in a frame only if the origin (domain) of the page embedding the content is the same as the origin of the page being embedded. This prevents external sites from being able to load the application in an iframe, preventing clickjacking attacks on a third-party site.
|
1 |
X-Frame-Options: SAMEORIGIN; |
ALLOW-FROM URI
This directive allows the page to be displayed in a frame only if the origin of the page embedding the content matches the specified URI.
|
1 |
X-Frame-Options: ALLOW-FROM https://trustfoundry.net; |
How to Implement X-Frame-Options
Nginx
Use the add_header directive. The add_header directive is used to add, replace, or clear response headers.
To find the header block in NGINX for updating server response headers, you’ll typically look within the server block of your NGINX configuration file. The location of this file may vary depending on your system, but common locations include /etc/nginx/nginx.conf or a directory like /etc/nginx/conf.d/.
Add the following data to the header block:
|
1 2 3 4 5 |
server { add_header X-Frame-Options "SAMEORIGIN"; } |
Apache
Update server response headers using the Header directive. The location of the Apache configuration file can vary depending on your system, but common locations include /etc/httpd/httpd.conf or /etc/apache2/apache2.conf. Additionally, Apache allows per-directory configuration through .htaccess files.
|
1 2 3 4 5 |
<IfModule mod_headers.c> Header always set X-Frame-Options "SAMEORIGIN" </IfModule> |
IIS
The following steps will set the X-Frame-Options header in IIS to allow iframes from the same origin.
In the Connections pane on the left side, navigate to your site (or the site you want to apply X-Frame-Options to).
In the middle pane, double-click on the “HTTP Response Headers” icon.
Add X-Frame-Options Header: In the Actions pane on the right side, click on “Add…”.
Set Header Values:
- Name: X-Frame-Options
- Value: SAMEORIGIN
This example sets the X-Frame-Options header to “SAMEORIGIN”, allowing the page to be displayed in a frame on the same origin. If you want to deny framing altogether, you can set the value to “DENY”.
Save Configuration: After adding the header, click on “OK” to save the configuration.
Restart IIS: For the changes to take effect, you may need to restart IIS. You can do this by clicking on the server name in the Connections pane, then clicking on “Restart” in the Actions pane on the right.
Depending on your application, consider implementing additional security headers such as X-Content-Type-Options and Referrer-Policy to enhance security.
X-Content-Type-Options
The X-Content-Type-Options HTTP response header is a security header that helps mitigate MIME-type confusion attacks. MIME-type confusion occurs when a web server interprets a file’s content type incorrectly, leading to potential security vulnerabilities. The X-Content-Type-Options header allows a web server to declare and enforce a strict MIME type checking policy, instructing the browser to interpret files in a specific way. Modern browsers do not do as much content sniffing and default to secure MIME types when usure, although it can still be used to strengthen the MIME type.
The header has a single directive:
nosniff
This directive prevents the browser from interpreting files as a different MIME type than declared by the server.
While using the X-Content-Type-Options header with the nosniff directive is generally a good security practice, there can be some common problems or considerations when implementing it:
Compatibility Issues
Some older browsers may not fully support the X-Content-Type-Options header. However, major modern browsers do support it, and its usage is generally recommended.
MIME Type Mismatch
If your web server is misconfigured and serves a file with an incorrect MIME type, enabling nosniff can prevent the browser from trying to interpret it as a different type. This might result in the browser refusing to render or execute the content.
Development and Debugging
During development, you might encounter situations where you’re experimenting with different file types or MIME types. In such cases, the strict enforcement of content types by nosniff can be a hindrance. Developers may need to ensure that the server is configured correctly.
CDN Considerations
If your website uses a Content Delivery Network (CDN), you need to ensure that the CDN is configured to pass along the X-Content-Type-Options header. Some CDNs might modify headers, potentially affecting the behavior of this security header.
Incompatibility with Resource Inlining
When using techniques like inline scripts or styles, ensuring the correct MIME type is declared in the Content-Type header becomes important. The nosniff directive can affect the browser’s behavior in such cases.
Dynamic Content Generation
If your server dynamically generates content and the MIME type is not correctly set, enabling nosniff might prevent the browser from rendering the content. Ensuring proper MIME type declarations in such scenarios is crucial.
Limited Protection
While X-Content-Type-Options provides a layer of protection, it’s not a comprehensive solution. It primarily addresses content type sniffing issues and may not prevent all types of content-related attacks.
It’s important to thoroughly test the implementation of the X-Content-Type-Options header in different scenarios and environments to ensure that it enhances security without causing unintended issues. Additionally, consider combining it with other security headers and best practices for a more robust security posture.
How to Implement X-Content-Type-Options
Nginx
Use the add_header directive. The add_header directive is used to add, replace, or clear response headers.
To find the header block in NGINX for updating server response headers, you’ll typically look within the server block of your NGINX configuration file. The location of this file may vary depending on your system, but common locations include /etc/nginx/nginx.conf or a directory like /etc/nginx/conf.d/.
|
1 |
add_header X-Content-Type-Options “nosniff”; |
Apache
Update server response headers using the Header directive. The location of the Apache configuration file can vary depending on your system, but common locations include /etc/httpd/httpd.conf or /etc/apache2/apache2.conf. Additionally, Apache allows per-directory configuration through .htaccess files.
|
1 2 3 4 5 |
<IfModule mod_headers.c> Header set X-Content-Type-Options “nosniff” </IfModule> |
IIS
Open IIS manager
Select your site.
In the middle panel, double-click on “HTTP Response Headers.”
On the right panel, click “Add” under the Actions sidebar.
Set the name to X-Content-Type-Options and the value to nosniff.
By carefully configuring these security headers, web developers can create a robust defense against a variety of web-based attacks, ensuring the confidentiality and integrity of user data.
Subresource integrity
Implementing Subresource Integrity (SRI) involves ensuring that the resources (such as scripts or stylesheets) loaded into a web page haven’t been tampered with. SRI allows browsers to verify that the fetched resource has been delivered without unexpected manipulation.
The following steps should be followed to implement Subresource Integrity:
Generate Integrity Hashes
For each external resource (like scripts, stylesheets, or fonts) you want to include with SRI, generate a hash using a hashing algorithm (like SHA-256). Various online tools or command-line utilities can help generate these hashes.
For instance, using a command-line tool (like OpenSSL or hashing tools in programming languages):
|
1 |
openssl dgst -sha256 -binary file.js | openssl base64 -A |
This command generates a SHA-256 hash of the content in file.js.
Add Integrity Attributes to Resource Tags
For each external resource tag (<script>, <link>, etc.), add the integrity attribute.
|
1 2 3 |
<script src="https://example.com/example.js" integrity="sha256-hash" crossorigin="anonymous"></script> <link href="https://example.com/example.css" integrity="sha256-hash" rel="stylesheet" crossorigin="anonymous"> |
- Ensure the integrity attribute contains the hash generated for the respective resource.
- Use the crossorigin=”anonymous” attribute to ensure proper functionality across various origins.
Verify Loading
Test the web page to confirm that the resources load correctly without any errors related to integrity checks.
Validate Hashes
Ensure the hashes in the integrity attribute match the calculated hashes for the resources. Any mismatch might indicate a problem with the resource or the generated hash.
Maintenance and Monitoring
Periodically recheck the resources’ integrity by regenerating the hashes and verifying them against the integrity attributes. This helps ensure ongoing security against potential tampering.
Access-Control-Allow-Origin
The Access-Control-Allow-Origin header is an HTTP header used in Cross-Origin Resource Sharing (CORS) to specify which origins (domains) are permitted to access the resources of a web server. CORS is a security feature implemented by web browsers that controls how web pages in one domain can request and interact with resources hosted on another domain.
When a web page makes a cross-origin HTTP request (i.e., a request to a different domain than the one that served the web page), the browser enforces the Same-Origin Policy by default, which restricts such requests for security reasons. However, CORS allows servers to relax these restrictions selectively.
The Access-Control-Allow-Origin header is part of the CORS mechanism and is included in the HTTP response from the server. It indicates to the browser which origin(s) are allowed to make requests to the server. The header can have the following options:
Wildcard (*): Any origin is allowed to access the resource. This is useful for public resources that should be accessible by any website.
|
1 |
Access-Control-Allow-Origin: * |
A specific origin: Only the specified origin is allowed to access the resource.
|
1 |
Access-Control-Allow-Origin: https://trustfoundry.net |
How to Implement Access-Control-Allow-Origin
Nginx
Open the Nginx configuration file for your website or application. This file is typically located in the /etc/nginx/sites-available/ directory. The main configuration file may be named nginx.conf or default depending on your setup.
Inside the server block, you can use the add_header directive to add the Access-Control-Allow-Origin header. For example:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 |
server { # ... other server configurations ... location / { # Add the following line to allow requests from a specific origin add_header Access-Control-Allow-Origin https://example.com; } } |
Apache
Open the Apache configuration file for your website or application. This file is often named httpd.conf or apache2.conf. You can also add the directive to a virtual host configuration file. Inside the <VirtualHost> block or relevant location, add the Header directive to set the Access-Control-Allow-Origin header. For example:
|
1 |
Header set Access-Control-Allow-Origin "*" |
IIS
Open IIS Manager:
Open the Internet Information Services (IIS) Manager on your Windows server.
Select Your Site:
In the Connections pane on the left, navigate to your site.
Install URL Rewrite Module (if not installed):
If the URL Rewrite module is not installed, you can install it through the “Server Manager” or download it from the official Microsoft site.
Open URL Rewrite:
Double-click on the “URL Rewrite” feature in the middle pane to open its configuration.
Add an Outbound Rule:
In the Actions pane on the right, click on “Add Rule(s)…” to add a new rule.
Choose the “Blank Rule” template for an outbound rule.
Configure the Outbound Rule:
In the “Edit Outbound Rule” dialog, set the following:
Name: Give your rule a descriptive name.
Match URL: Set the conditions for when the rule should be applied. You can leave this blank to apply the rule to all responses.
Action: Set the action type to “Custom Response.”
Custom Response: Set the headers you want to add. Add the Access-Control-Allow-Origin header, and potentially other CORS headers.
|
1 |
Access-Control-Allow-Origin: https://example.com |
To summarize, Configuring HTTP response headers is crucial for web security, performance, and interoperability. These headers provide instructions and information to browsers and other clients, helping to enhance security by preventing certain types of attacks, such as cross-site scripting (XSS) and clickjacking. They also enable features like content caching, compression, and browser compatibility, thereby improving website performance. Additionally, proper configuration of HTTP response headers ensures compliance with web standards and regulations, enhancing the overall user experience and trustworthiness of the website.
