HTTP Header Scanner
Check Your Security Headers
Http headers
x-frame-options | Specifies whether browser should show page in an iFrame |
x-xss-protection | Enables Cross Site Scripting (XSS) filtering |
x-content-type-options | Disables MIME Sniffing and forces browser to use type shown in Content-Type |
x-ua-compatible | Compatiability header for old versions of Microsoft Internet Explorer (IE) and Edge |
strict-transport-security | HSTS informs browser to use HTTPS not HTTP |
p3p | Privacy Protocol that was not widely adopted |
referrer-policy | Rules which referrer information sent in the referrer header is incorporated with requests |
content-security-policy | Controls which resources the client can load for the page |
access-control-allow-origin | Details whether the response can be shared. |
access-control-allow-credentials | Header tells browser whether to expose the response to frontend JavaScript |
access-control-max-age | It indicates how long the results of a preflight request can be cached. |
access-control-allow-methods | Specifies the method or methods allowed when accessing the resource in response to a preflight request. |
access-control-allow-headers | Indicate which HTTP headers can be used during the actual request. |
access-control-expose-headers | Allows a server to indicate which response headers should be made available to scripts running in the browser, in response to a cross-origin reques |
content-encoding | Specifies compression type |
vary | Details how to determine if cache can be used rather than a new response from server |
x-powered-by | Hosting and Backend Server Frameworks may use this. Can reveal sensitive information (version and software). |
www-authenticate | Defines the authentication method that should be used to gain access to a resource. |
cache-control | Details caching options in requests and responses |
pragma | Related to caching, may be implemented in different ways. |
age | Time in seconds resource has been in proxy cache |
connection | Controls network connection |
cookie-security | A small piece of data that a server sends to the users web browser. |
expect-ct | Reporting and enforcement of Certificate Transparency. Prevents the use of mis-issued certificates for the site. When enabled the Expect-CT header requests that Chrome checks certificates for the site appear in public CT logs. |
timing-allow-origin | specifies origins that are allowed to see values of attributes retrieved via features of the Resource Timing API, which would otherwise be reported as zero due to cross-origin restrictions. |
custom-headers | Custom HTTP headers are commonly meant to provide additional information that may be pertinent to a web developer, or for troubleshooting purposes. |
x-dns-prefetch-control | HTTP response header controls DNS prefetching, a feature by which browsers proactively perform domain name resolution on both links that the user may choose to follow as well as URLs for items referenced by the document, including images, CSS, JavaScript, and so forth. |
x-download-options | Specific to IE8. Stops downloads opening directly in browser. |
x-permitted-cross-domain-policies | The X-Permitted-Cross-Domain-Policies header tells clients like Flash and Acrobat what cross-domain policies they can use. |
report-to | Header used for adding troubleshooting information |
feature-policy | provides a mechanism to allow and deny the use of browser features in its own frame, and in content within any iframe elements in the document. |
permissions-policy | The Permissions-Policy HTTP header replaces the existing Feature-Policy header for controlling delegation of permissions and powerful features. |
clear-site-data | The Clear-Site-Data header clears browsing data (cookies, storage, cache) associated with the requesting website. |
content-type | Denotes the type of media |
cross-origin-resource-policy | The HTTP Cross-Origin-Resource-Policy response header conveys a desire that the browser blocks no-cors cross-origin/cross-site requests to the given resource. |
nel | An option for developers to set network error reporting. |
cross-origin-embedder-policy | The HTTP Cross-Origin-Opener-Policy (COOP) response header allows you to ensure a top-level document does not share a browsing context group with cross-origin documents. |
cross-origin-opener-policy | The HTTP Cross-Origin-Opener-Policy (COOP) response header allows you to ensure a top-level document does not share a browsing context group with cross-origin documents. |
x-robots-tag | Allows you to choose content search engines can crawl on the site |
What are HTTP Security Headers?
HTTP security headers are directives issued by a web server to a browser, guiding how the browser should handle a website’s content. These headers serve as a vital security layer, helping to safeguard websites and their users against threats like clickjacking, cross-site scripting (XSS), cross-site request forgery (CSRF), and other cyberattacks.
Beyond security, HTTP headers also allow you to manage cross-origin resource sharing (CORS), regulate MIME types, and enforce content security policies, ensuring a more secure and controlled browsing experience.
Why OWASP Recommendation Secure Headers Matter?
OWASP is a globally respected organization committed to enhancing web security. Their OWASP Secure Headers Project outlines industry best practices for securing web applications. Implementing OWASP-recommended HTTP security headers helps protect users, strengthen your website’s defenses, and reinforce a secure online environment.
OWASP recommends the following HTTP response headers:
- Strict-Transport-Security (HSTS)
- X-Frame-Options
- X-Content-Type-Options
- Content-Security-Policy (CSP)
- X-Permitted-Cross-Domain-Policies
- Referrer-Policy
- Clear-Site-Data
- Cross-Origin-Embedder-Policy (COEP)
- Cross-Origin-Opener-Policy
- Cross-Origin-Resource-Policy (CORP)
- Cache-Control
LET'S WORK TOGETHER
we love to listen to your requirements
If you have a design project you would like us to quote, please send us a message outlining your ideas. If we are able to take on your project, we will be in touch with details and any additional questions we may have in order to provide an accurate quote for your project.
Frequently asked questions
What are HTTP security headers?
HTTP security headers are directives communicated from a web server to a client's browser, instructing it on how to handle the website's content securely. They play a pivotal role in safeguarding both the website and its users from various security threats.
Why are HTTP security headers important?
They enhance the security of web applications by mitigating common vulnerabilities such as cross-site scripting (XSS), clickjacking, and content sniffing. Properly configured headers ensure that browsers interpret and display content as intended, reducing the risk of exploitation.
What are some commonly used HTTP security headers?
Common headers include:
- Content-Security-Policy (CSP): Controls resources the user agent is allowed to load for a given page.
- Strict-Transport-Security (HSTS): Enforces secure (HTTPS) connections to the server.
- X-Content-Type-Options: Prevents browsers from interpreting files as a different MIME type.
- X-Frame-Options: Protects against clickjacking by controlling whether a page can be framed.
- X-XSS-Protection: Enables cross-site scripting filtering.
- Referrer-Policy: Controls how much referrer information is included with requests.
How does the Content-Security-Policy (CSP) header enhance security?
CSP specifies which content sources are trusted, thereby preventing the browser from loading malicious assets like scripts, styles, or media from untrusted origins. This significantly reduces the risk of XSS attacks.
What is the role of the Strict-Transport-Security (HSTS) header?
HSTS instructs browsers to interact with the server only over HTTPS, even if users attempt to access the site via HTTP. This ensures encrypted communication and protects against protocol downgrade attacks.
How can I check if my website has implemented HTTP security headers?
You can use our tools to scan your website and receive a report on the security headers in place
Are HTTP security headers a replacement for other security measures?
No, they complement other security practices such as secure coding, regular updates, and vulnerability assessments. While they add an essential layer of defense, relying solely on headers is insufficient for comprehensive security.
Can implementing security headers affect website functionality?
Yes, if misconfigured, they can restrict legitimate content or functionalities. It's crucial to test changes in a development environment before deploying them live to ensure they don't interfere with user experience.
How often should I review and update my HTTP security headers?
Regularly, especially after significant website changes or updates. As new threats emerge, periodically reviewing and adjusting your security headers ensures ongoing protection against evolving vulnerabilities.
Where can I find best practices for configuring HTTP security headers?
Resources like the Articles provide comprehensive guidelines on setting up security headers effectively.
