The most essential part for any website is about HTTP security headers. The first thing the server sends in response to the user is HTTP headers that define whether the website is safe or not for the user.
What is the header?
A header is a section of a document, data packet, or message that carries crucial information in addition to the data itself. The header’s contents differ from document to document. The header contains metadata which means data about data. Headers are seen in any type of file such as email, HTML document, software, and even in word or excel files.
Here are some header content examples:
Archive or binary file: The header of an archive or binary file provides a signature, identifying the file format and suitable software that may be used to open/edit the file.
Data packet: The header portion of a data packet transferred over the Internet contains the payload type, sequence number, sender and recipient IP addresses, etc.
Email: The email header comes before the text message included within the email. It provides information such as the sender, receiver, subject, date, and other pertinent information.
Graphics design: A graphics design’s header provides information on the image’s size (width and height), depth, resolution, format, number of colours, etc.
HTML document: The header section of an HTML document is specified by the <head> element and is used to carry metadata and the title of the HTML content.
HTTP message: Every HTTP message includes a header that provides information about the content type, HTTP version, user agent, etc.
Source code for the program: Header files add processing information and/or assembly files to a source file.
Word processing documents: The header of a word processing document is used for extra information such as the author’s name, the number of pages, the date, and so on.
What is an HTTP response header?
An HTTP response header is used primarily to communicate with and respond to user requests received on a Web server or website. An HTTP response header is sent when the client’s Web browser creates a website request or HTTP request. This request is sent to the Web server in an HTTP request header, including the source address, requested data, format, and other information. The Web server generates an HTTP response header and appends the requested data. The HTTP response header contains the destination IP address, data type, host address, etc.
Sometimes, some header set by the programmer or code doesn’t work in the web browser. The problem is the header is not executed by the web browser.
The work of response headers is how the client’s web browser behaves with the website’s content. After that programmer can quickly know how to treat and which content should execute or not in the metadata.
What is an HTTP security header?
Security headers come into play when an unintentional security event to a website is vulnerable. For example, when a website is loading in the browser and a script can also be executed in that time, it is vulnerable to cross-site scripting.
The metadata in request messages can include the following information:
- The request’s language
- Credentials for the website in the form of cookies
- Data caching
The metadata in response messages can include the following information:
- The size and kind of content
- Preferences for cache storage
- Data from the server
- Date and time
- The customer will establish the credentials
Security headers are HTTP response headers that specify whether security precautions should be activated or deactivated on the web browser.
With the help of correct headers, client-side attacks can be reduced. It can prevent a low level of security such as clickjacking, code injection, cross-site scripting, etc.
Some essential security headers are crucial to implementing in all the websites. Most of the websites use the necessary headers. In case essential security headers are not implemented. Some web app scanners such as netsparker, accunetix, and other tools can detect it easily. It is also known as the first line of defence for web applications.
The easiest part of securing a website is implementing headers. Still, framing headers correctly is tricky sometimes because you play with values and the origins. If the origins or sources are not defined precisely, it will create a new vulnerability.
Types of HTTP Security Headers
There are nine types of HTTP security headers present and are as follows:
- Clear-Site-Data
- Content Security Policy (CSP)
- Cross-Origin-Embedder-Policy (COEP)
- Cross-Origin-Opener-Policy (COOP)
- Cross-Origin-Resource-Policy (CORP)
- Expect-CT
- Referrer-Policy
- Strict Transport Security (HSTS)
- X-Content-Type-Options
- X-Frame-Options
- X-XSS-Protection
Clear-Site-Data
Clearing browsing data (cookies, storage, cache) connected with the requesting page is accomplished through the Clear-Site-Data header. It gives web creators more control over the data that a client browser stores for its sources.
This HTTP header is only available in secure contexts (HTTPS). It is supported by specific or all web browsers.
Syntax of Clear-Site-Data:
Clear-Site-Data: "cache" Clear-Site-Data: "cache", "cookies" Clear-Site-Data: "*"
Directives of Clear-Site-Data:
cache: This indicates that the server desires to erase locally cached data (the browser cache, see HTTP caching) for the response URL’s origin. Depending on the browser, this may also clean up pre-rendered pages, script caches, WebGL shader caches, or address bar recommendations.
cookies: This indicates that the server wants to delete all cookies associated with the origin of the response URL. The HTTP login credentials are also removed. This has an impact on the whole registered domain, including subdomains. Cookies will be cleared for both https://example.com and .
storage: This indicates that the server desires to delete all DOM storage for the response URL’s origin. This includes storage mechanisms such as localStorage (executes localStorage.clear), sessionStorage (executes sessionStorage.clear), IndexedDB, Service worker registrations, WebSQL databases, FileSystem API data, Plugin data.
executionContexts: The server wants to refresh all browsing contexts for the response’s origin (Location.reload).
* (wildcard): This indicates that the server wants to clear all sorts of data for the response’s origin. If different data types are introduced in future versions of this header, they will also be covered.
Content Security Policy (CSP)
Content Security Policy (CSP) comes into use when a website fetches resources from the same server or another server. These resources include CSS files, JavaScript files, images, iframe, etc. It is okay if the website is fetching resources from a secure website. If not, it will trigger some attacks such as clickjacking, HTML injection attacks, etc. Only resources from secure websites are fetched with the help of CSP as it monitors all the sources.
CSP is an additional layer of security that aids in detecting and mitigating specific kinds of threats such as cross-site scripting (XSS), HTML injection attacks, and data injection attacks. These attacks are used for various purposes, including data theft, website defacement, and malware delivery.
CSP is intended to be entirely backwards compatible (except CSP version 2, where there are some explicitly-mentioned inconsistencies in backward compatibility). Web browsers that do not support it continue to interact with servers and vice versa. Browsers that do not support CSP ignore it and continue to function as usual and defaulting to the standard same-origin policy for web content. If the website does not include the CSP header, browsers fall back on the conventional same-origin approach.
CSP allows you to precisely control authorized content sources and many other parameters. It requires careful timing and precise definition of the policy.
Syntax of CSP:
Content-Security-Policy: default-src 'self' example.com *.example.com
Cross-Origin-Embedder-Policy (COEP)
The HTTP Cross-Origin-Embedder-Policy (COEP) response header forbids a document from loading any cross-origin resources that are not expressly granted access to the page using CORP or CORS.
Syntax of COEP:
Cross-Origin-Embedder-Policy: unsafe-none | require-corp
Directives of COEP:
unsafe-none: Allows the page to fetch cross-origin resources without specifying granting permission via the CORS protocol or the Cross-Origin-Resource-Policy header. This is the default option.
require-corp: Allows the page to fetch cross-origin resources without specifying granting permission via the CORS protocol or the Cross-Origin-Resource-Policy header. This is the default option.
Cross-Origin-Opener-Policy (COOP)
You can use this HTTP response header to guarantee that a top-level document does not share a browsing context group with cross-origin documents.
COOP will process and isolate your document. Prospective attackers will be unable to access your global object if they open it in a popup, avoiding XS-Leaks.
Suppose a cross-origin document with COOP is opened in a new window. In that case, the opening document does not have a reference to it and the new window’s window.opener attribute is null. This gives you greater control over window references than rel=noopener, which only affects outgoing navigations.
Syntax of COOP:
Cross-Origin-Opener-Policy: unsafe-none Cross-Origin-Opener-Policy: same-origin-allow-popups Cross-Origin-Opener-Policy: same-origin
Directives of COOP:
unsafe-none: Allows the document to be included in its opener’s browsing context group, unless it has a COOP of same-origin or same-origin-allow-popups. This is the default option.
same-origin-allow-popups: Retains references to freshly launched windows or tabs that either does not set COOP or opt-out of isolation by using unsafe-none as the COOP.
same-origin: Isolates the browsing environment to just documents of the exact origin. Documents from different origins are not loaded in the same browsing context.
Cross-Origin-Resource-Policy (CORP)
Cross-Origin Resource Policy is a policy defined by the CORP HTTP header. It allows websites and applications to protect against specific requests from other origins, such as those issued with elements like <script> and <img> to mitigate Spectre and Cross-Site Script Inclusion attacks.
CORP adds an extra layer of security to the default same-origin policy and works in combination with Cross-Origin Read Blocking (CORB). This method prevents some cross-origin reads by default.
Because this policy is presented in a response header. The actual request is not blocked. Instead, the browser protects the result from being disclosed by stripping the response body.
Syntax of CORP:
Cross-Origin-Resource-Policy: same-site | same-origin | cross-origin
Directives of CORP:
same-site: The resource can only be viewed by requests from the same website.
same-origin: The resource can only be viewed by requests from the exact origin, scheme + host + port.
cross-origin: The resource may be viewed by requests from any origin, including same-site and cross-site. This is useful when using COEP.
Expect-CT
The Expect-CT header enables websites to opt into reporting and/or enforcement of Certificate Transparency standards, preventing the usage of incorrectly issued certificates for that website from being undetected.
Syntax of Expect-CT:
Expect-CT: report-uri="<uri>", enforce, max-age=<age>
Directives of Except-CT:
max-age: The number of seconds after receiving the Expect-CT header field, the user agent should consider the received message’s host to be a known Expect-CT host. If a cache gets a number more significant than it can represent, or if any of its subsequent computations overflow, the cache will consider this value to be either 65536 (2^16) or the largest positive integer it can represent.
report-uri=”<uri>”: The URI where Expect-CT errors should be reported by the user agent. When the enforce directive is present, the configuration is referred to as an “enforce-and-report” configuration. It indicates to the user agent that compliance with the Certificate Transparency policy should be enforced and violations reported. This is an optional argument.
enforce: It signals to the user agent that compliance with the Certificate Transparency policy should be implemented rather than reporting compliance. The future connection that violates the Certificate Transparency policy should be refused. When both the enforce directive and the report-uri directive are present, the configuration is known as an “enforce-and-report” configuration. It indicates to the user agent that compliance with the Certificate Transparency policy should be enforced and infractions reported.
Strict Transport Security (HSTS)
Suppose a website allows an HTTP connection and redirects to HTTPS. In that case, users may communicate with the non-encrypted version of the website before being redirected. For example, if the visitor types http://www.example.com/ or even just example.com.
This opens the door for a man-in-the-middle attack. The redirect might be used to send users to a malicious website rather than the secure version of the original website.
A strict Transport Security header reminds the browser that it should never load a website via HTTP and transform all HTTP queries to HTTPS ones.
Strict Transport Security (HSTS) enforces encrypted HTTPS connections rather than plain text HTTP communication. HSTS helps to protect websites against protocol downgrade attacks and decrypting the data.
The Internet Engineering Task Force (IETF) standard is specified in RFC 6797 about policy and requirements in HSTS.
Syntax of HSTS:
Strict-Transport-Security: max-age=<expire-time> Strict-Transport-Security: max-age=<expire-time>; includeSubDomains Strict-Transport-Security: max-age=<expire-time>; preload
Directives of HSTS:
max-age=<expire-time>: The amount of time, in seconds, that the browser should remember that a website should only be viewed through HTTPS.
includeSubDomains: With this argument, HSTS will treat all the subdomains the same as the primary domain. This is an optional argument but valuable if a website has subdomains.
preload: With this argument, some web browsers such as google chrome, firefox, brave, and so on can list and save your domain as preload. Suppose any web browser saved your domain as preload. When a user navigates to your website, it is not counted as the first time as it is already preloaded. This is an optional argument but useful to save from attacks.
X-Content-Type-Options
The server uses the X-Content-Type-Options HTTP response header to signal that the MIME types are indicated in the Content-Type headers. X-Content-Type-Options header should be followed and should not be modified. The header prevents Multipurpose Internet Mail Extensions (MIME) type snooping by stating that the MIME types are intentionally specified.
Hackers can easily sniff and manipulate the content type to upload malicious scripts if this header is not implemented. This header has only one value or directive that is nosniff.
Microsoft introduced this header in Internet Explorer 8 as a technique for webmasters to prevent content sniffing and convert non-executable MIME types into executable MIME types. Since then, other browsers have adopted it even though their MIME sniffing techniques are less intrusive.
Syntax for X-Content-Type-Options:
X-Content-Type-Options: nosniff
Directives for X-Content-Type-Options
nosniff: If the request destination is of typestyle and the MIME-type is not the text/css, or typescript and the MIME-type is not a JavaScript MIME type, the request is blocked.
X-Frame-Options
This HTTP response header can be used to specify whether a browser should be authorized to render a page in a <frame>, <iframe>, <embed>, or <object>. Websites may utilize this to avoid click-jacking attacks by ensuring that their content is not incorporated in the content of other websites.
The additional protection is only available if the person accessing the content uses a browser that supports X-Frame-Options.
This header instructs the browser whether the content can be displayed within frames. It improves the protection of web applications against clickjacking. It can be ignored if the Content Security Policy frame-ancestors is used.
The syntax for X-Frame-Options:
X-Frame-Options: DENY X-Frame-Options: SAMEORIGIN
Directive for X-Frame-Options:
If you choose DENY, the browser will not only fail to load the page in a frame when loaded from other websites, but it will also fail when loaded from the same website. However, if you choose SAMEORIGIN, you may still utilize the page in a frame as long as the website put it in a frame is the same as the one supplying the page.
DENY: Regardless of the website’s effort, the page cannot be shown in a frame.
SAMEORIGIN: The page can only be seen in a frame with the exact origin of the page itself. The standards leave browser vendors to determine whether this option applies to the top level, the parent, or the entire chain. It is claimed that the option is not particularly helpful until all predecessors have the exact origin.
ALLOW-FROM URI: Current web browsers no longer support this out-of-date directive. It should not be used. A page can only be shown in a frame on the provided origin URI to support outdated browsers. It’s worth noting that this still had the same issue as SAMEORIGIN in the old Firefox implementation — it doesn’t verify the frame antecedents to determine whether they’re in the exact origin. You can use the frame-ancestors directive instead of the Content-Security-Policy HTTP header.
Referrer-Policy
Referrer-Policy The HTTP header specifies how much referral data (sent with the Referrer header) should be included with requests. This policy can also be defined in HTML and the HTTP header.
This policy exposes potentially sensitive information from HTTPS resource URLs to untrusted sources. Understand the impacts of this setting carefully.
Syntax of Referrer-Policy:
Referrer-Policy: no-referrer Referrer-Policy: no-referrer-when-downgrade Referrer-Policy: origin Referrer-Policy: origin-when-cross-origin Referrer-Policy: same-origin Referrer-Policy: strict-origin Referrer-Policy: strict-origin-when-cross-origin Referrer-Policy: unsafe-url
Directive of Referrer-Policy:
no-referrer: The Referer header will be ignored since transmitted requests include no referrer information.
no-referrer-when-downgrade: When the protocol security level remains the same or improves (HTTP→HTTP, HTTP→HTTPS, HTTPS→HTTPS), send the origin, path, and query string in Referer. Do not transmit the Referer header for queries to less secure destinations (HTTPS→HTTP, HTTPS→file).
origin: In the Referer header, just the origin is sent. A document at , for example, will transmit the referrer https://example.com/.
origin-when-cross-origin: Send the origin, path, and query string when making a same-origin request to the same protocol level (HTTP→HTTP, HTTPS→HTTPS). Send just the origin for cross-origin requests and requests to less secure destinations (HTTPS→HTTP).
same-origin: For same-origin requests, include the origin, path, and query string. For cross-origin queries, do not transmit the Referer header.
strict-origin: When the protocol security level remains constant (HTTPS→HTTPS), send just the origin. Sending the Referer header to less secure locations (HTTPS→HTTP) is not recommended.
strict-origin-when-cross-origin: When making a same-origin request, including the origin, path, and query string. When the protocol security level remains the same (HTTPS→HTTPS), send the origin (only) for cross-origin requests. Sending the Referer header to less secure locations (HTTPS→HTTP) is not recommended.
unsafe-url: When making any request, regardless of security, send the origin, path, and query string.
X-XSS-Protection
When Internet Explorer, Chrome, or Safari detects reflected cross-site scripting (XSS) attacks, this response header prevents pages from loading, and nothing shows up.
When websites adopt a strong Content-Security-Policy that prevents the usage of inline JavaScript (‘unsafe-inline’), these protections are usually unnecessary in recent browsers.
Syntax of X-XSS-Protection:
X-XSS-Protection: 0 X-XSS-Protection: 1 X-XSS-Protection: 1; mode=block X-XSS-Protection: 1; report=<reporting-uri>
Directives of X-XSS-Protection:
0: It will disable the XSS filtering.
1: Filtering for XSS is enabled (usually default in browsers). The browser will sanitize the page if a cross-site scripting attack is detected the remove the unsafe parts.
1; mode=block: Filtering for XSS is enabled. If an attack is identified, the browser will block the page from being rendered rather than cleaning it.
1; report=<reporting-URI>: Filtering for XSS is enabled. If a cross-site scripting attack is discovered, the browser will sanitize the page and notify the user. This takes advantage of the CSP report-uri directive’s capabilities to submit a report. This argument is only available in the chromium web browser.
Conclusion
Now, we have discussed some main and other HTTP headers used nowadays. Maybe some of the HTTP headers will be replaced with new ones with more features.
Understand the main five headers. They are Content Security Policy, Strict Transport Security (HSTS), X-Content-Type-Options, X-Frame-Options, Referrer-Policy. These headers prevent more critical vulnerabilities from small business websites to large e-commerce websites.
