HTTP Security Headers
Security headers are directives used by web applications to configure security defenses in web browsers. Based on these directives, browsers can make it harder to exploit client-side vulnerabilities such as Cross-Site Scripting or Clickjacking. Headers can also be used to configure the browser to only allow valid TLS communication and enforce valid certificates, or even enforce using a specific server certificate.
Strict-Transport-Security
The Strict-Transport-Security (HSTS) header is a security feature used by websites to protect users from certain types of cyberattacks. Its primary purpose is to ensure that web browsers only connect to a website using a secure, encrypted connection (HTTPS), making it harder for attackers to intercept or manipulate data transmitted between the user and the website.
The Strict-Transport-Security header has a value that consists of several components:
- max-age: This specifies the time, in seconds, that the browser should remember to only use HTTPS for the website. For example, “max-age=31536000” means the browser will remember this setting for one year.
- includeSubDomains: If present, this part tells the browser to apply the HSTS policy to all subdomains of the website as well. For example, “includeSubDomains” means all subdomains are covered.
- preload: Websites can submit their HSTS settings to be preloaded into major web browsers. This ensures that even a user’s first visit to the site is secure. Including “preload” in the header indicates that the site wants to be part of this preload list.
Sample header
Strict-Transport-Security: max-age=31536000; includeSubDomains; preloadThe Strict-Transport-Security (HSTS) header instructs the browser to only connect to the website over a secure (HTTPS) connection. In the sample header, max-age specifies the duration (in seconds) for which the browser should enforce this policy (here, 31,536,000 seconds, which is one year). includeSubDomains indicates that the policy applies to all subdomains, and preload signifies that the site can be included in browser preload lists for enhanced security.
X-Frame-Options
The X-Frame-Options header is a security feature used by web servers to control how a web page can be displayed within an iframe on another website. Its primary purpose is to prevent clickjacking attacks, which occur when a malicious website tries to trick a user into clicking on something different from what they perceive.
The X-Frame-Options header has a value that consists of several components:
- DENY: When set to “DENY,” it means that the web page cannot be displayed in an iframe on any other website. This is the strictest option and provides maximum security.
- SAMEORIGIN: When set to “SAMEORIGIN,” it allows the web page to be displayed in an iframe, but only if the embedding website is from the same origin (i.e., the same domain and protocol). This is a more permissive option but still provides reasonable security.
- ALLOW-FROM uri: This option allows you to specify a specific URI (Uniform Resource Identifier) from which the web page can be embedded in an iframe. It restricts embedding to a specific source.
Sample Header
X-Frame-Options: DENYThe X-Frame-Options header helps prevent clickjacking attacks by specifying whether a web page can be embedded within an iframe. In this sample header, DENY means the page cannot be embedded in any frame, providing protection against clickjacking.
X-Content-Type-Options
The X-Content-Type-Options header is a security feature implemented in web browsers to enhance the security of web applications. Its primary purpose is to prevent a certain type of web vulnerability known as MIME sniffing or content-type sniffing.
The X-Content-Type-Options header has a value that consists of several components:
- nosniff — This is the recommended and widely used value. When set to “nosniff,” it instructs the browser to strictly follow the content type provided in the response’s Content-Type header. If the content type is declared as “text/html,” the browser will treat it as HTML, even if the server sends it with a different MIME type.
- none — This value effectively disables the X-Content-Type-Options header. It allows browsers to perform content-type sniffing, which can potentially lead to security vulnerabilities.
Sample Header
X-Content-Type-Options: nosniffThe X-Content-Type-Options header prevents browsers from interpreting files as a different MIME type than what is declared by the server. In this sample header, nosniff instructs the browser not to “sniff” the content type and to respect the declared MIME type.
Content-Security-Policy
The Content-Security-Policy (CSP) header is a security feature used by websites to control and specify how resources on a web page can be loaded and executed. It’s like setting rules for who can enter your house and what they can do once they’re inside. This header helps protect websites and their visitors from various types of cyberattacks, such as cross-site scripting (XSS) and data injection.
The Content-Security-Policy header has a value that consists of several components:
- default-src: Specifies the default source for various resource types if not explicitly defined by other directives.
- script-src: Controls which sources can load JavaScript code. For example, ‘self’ allows scripts from the same origin (your own website), while ‘unsafe-inline’ permits inline scripts, but this is considered risky.
- style-src: Determines the sources from which stylesheets (CSS) can be loaded. Similar to script-src, it can include values like ‘self’ and ‘unsafe-inline’.
- img-src: Specifies allowed sources for images. ‘self’ permits images from your website, and you can add other domains as well.
- font-src: Manages the sources for web fonts.
- connect-src: Governs which domains can be accessed via network requests, like AJAX or Fetch API calls.
- frame-src: Controls where your web page can be embedded in an iframe.
- report-uri or report-to: Specifies where to send violation reports if the CSP is breached. It’s useful for monitoring and debugging.
Sample Header
Content-Security-Policy: default-src 'self'; script-src 'self' cdn.example.com; img-src data:; upgrade-insecure-requestsThe Content-Security-Policy header defines which resources can be loaded and executed on a web page, helping to mitigate various types of attacks like cross-site scripting (XSS) and data injection. In this sample header, it allows scripts to be loaded only from the same origin and from a specific CDN, allows images from data URIs, and enables automatic upgrading of insecure HTTP requests to HTTPS.
Tool to check misconfigured CSP Header: https://csp-evaluator.withgoogle.com
Cache-Control
The Cache-Control header is an important part of HTTP (Hypertext Transfer Protocol) used for communication between web clients (like browsers) and servers. This header plays a crucial role in controlling how web content is cached, stored, and retrieved by the client and intermediary devices, such as proxies and CDNs (Content Delivery Networks).
The Cache-Control header has a value that consists of several components:
- public: Indicates that the response can be cached by any intermediate cache, like a CDN or proxy server. It’s suitable for content that can be shared among multiple users.
- private: Specifies that the response is intended for a single user and should not be cached by intermediate caches. This is often used for sensitive or personalized content.
- max-age: This value defines the maximum time (in seconds) a response can be cached before it’s considered stale. For example, “max-age=3600” means the response can be cached for one hour.
- no-store: Instructs the client and intermediaries not to store a cached copy of the response. It must be fetched from the server every time it’s needed. This is used for highly sensitive data.
- no-cache: Tells the client to revalidate the cached content with the server before using it, even if it’s not expired. This ensures that the cached content is still fresh.
- must-revalidate: This directive indicates that the cached content must be revalidated with the server before use, regardless of its expiration time.
- s-maxage: Similar to “max-age,” but specifically for shared caches (like proxies and CDNs). It sets the maximum age for cached content in shared caches.
Sample Header
Cache-Control: no-store, no-cache, must-revalidate, max-age=0The Cache-Control header controls caching behavior in the browser and intermediary caches. In this sample header, it directs browsers and caches not to store or cache the response, always revalidate it with the server, and sets the maximum age to 0 seconds, effectively preventing any caching.
Referrer-Policy
The Referrer-Policy header is a security feature implemented by web browsers to control how much information a web page should share about the user’s previous web activity (referrer) when they click on a link or navigate to a new page. This header helps protect user privacy and security by allowing website owners to specify how much referrer information should be disclosed to the destination website.
The Referrer-Policy header has a value that consists of several components:
- no-referrer: This value means that no referrer information will be sent to the destination website. It provides the highest level of privacy but may break some functionality on certain websites.
- no-referrer-when-downgrade: This value is the default setting if the header is not specified. It sends the full referrer when navigating from an HTTPS site to an HTTP site, but it sends no referrer when moving from an HTTPS site to another HTTPS site. This helps maintain security during downgrades from secure to non-secure connections.
- same-origin: It only includes the referrer information if the source and destination URLs have the same origin (same protocol, domain, and port). This is useful for preserving privacy while still allowing referrer information within a website.
- origin: It includes only the origin part of the referrer URL (protocol, domain, and port), but not the path or query parameters. This helps protect privacy while allowing some context.
- strict-origin: Similar to “origin,” but it only sends a referrer when the source and destination URLs have the same origin.
- origin-when-cross-origin: It sends the full referrer when navigating within the same origin but only the origin part when moving to a different origin. This balances privacy and functionality.
- strict-origin-when-cross-origin: Similar to “origin-when-cross-origin,” but it only sends a full referrer when the source and destination URLs have the same origin.
- unsafe-url: It sends the full referrer information, including sensitive path and query parameters, to all destinations. This option provides the least privacy and should be used with caution.
Sample Header
Referrer-Policy: strict-origin-when-cross-originIn this sample header, the website is instructing the browser to only include the full referrer information when navigating to a different origin (i.e., a different website). If you’re moving within the same website (same origin), it will only share the origin part of the referrer URL. This setting strikes a balance between privacy and functionality.
Tools to check header information
#cybersecurity #security #penetrationtesting #bugbounty #bugbountytips #bounty #pentesting #securityheader #learn
Linkedin: https://linkedin.com/in/piyush-kumawat
Website: https://securitycipher.com
Twitter: https://twitter.com/piyush_supiy
Github: https:/github.com/securitycipher
