Zabezpečenie vašej webovej aplikácie pomocou HTTP bezpečnostných hlavičiek

Hardening your web application with HTTP security headers

Securing web applications is crucial in today’s digital world. While many developers focus on code-level security measures, HTTP security headers offer an additional, vital layer of defense. HTTP headers instruct browsers on how to handle the communication between client and server, and configuring them correctly can prevent numerous security vulnerabilities, including clickjacking, cross-site scripting (XSS), and data leakage.

In this article, we'll explore some of the most critical HTTP response headers, explain how they protect your web applications, discuss what can happen if they are not used or misconfigured, and provide best practices for configuring them.

What are HTTP Security Headers?

HTTP security headers are directives included in the HTTP response sent from the server to the client. These headers provide instructions on how to handle the resources, enhancing the security of your web application. They can restrict how certain content can be used, define trusted sources, and enforce secure connections, among other things.

In the absence of proper HTTP security headers, a web application becomes vulnerable to various types of attacks, including cross-site scripting (XSS), clickjacking, and man-in-the-middle (MITM) attacks.

Why are HTTP Security Headers Important?

Security headers help mitigate common attacks on web applications. Many vulnerabilities result from the way browsers interpret and execute scripts and data. By sending well-configured security headers, you can guide the browser on how to safely handle your website's content. This reduces the risk of exploitation from bad actors.

For example:

Clickjacking: Without proper headers, an attacker can trick users into clicking on hidden elements within an iframe, leading to malicious actions.
XSS Attacks: If the headers aren’t correctly set, browsers may inadvertently execute injected scripts from an untrusted source, leading to data theft, unauthorized actions, or other malicious activities.
Data leakage: Headers can prevent the sharing of sensitive information with unintended third parties.

By correctly configuring these headers, you close down attack vectors that hackers can exploit.

Essential HTTP Security Headers

X-Frame-Options

The X-Frame-Options header controls whether a browser is allowed to display a webpage in a <frame>, <iframe>, or <object>. This header is primarily used to prevent clickjacking attacks.

Recommendation: X-Frame-Options: DENY
Usage: When set to DENY, this header blocks any webpage from being displayed in a frame or iframe, preventing attackers from embedding your page within their own malicious website.
What happens if not used: Without this header, your site can be loaded into an iframe, making it vulnerable to clickjacking attacks where a user is tricked into interacting with a hidden frame that is controlled by an attacker.

X-Content-Type-Options

This header prevents the browser from MIME-sniffing a response away from the declared Content-Type. This is particularly useful for preventing attacks based on improperly identified content types.

Recommendation: X-Content-Type-Options: nosniff
Usage: Setting this header to nosniff ensures that the browser does not override the content type, which could lead to security risks.
What happens if not used: Without this header, an attacker can potentially exploit MIME-sniffing behavior to serve malicious content as legitimate media (e.g., turning a text file into an executable).

Referrer-Policy

The Referrer-Policy header controls how much referrer information should be included with requests.

recommendation: Referrer-Policy: strict-origin-when-cross-origin
usage: This setting ensures that the full URL is sent as the referrer only for same-origin requests, while cross-origin requests only send the origin part of the URL. This limits potential leakage of sensitive information.
What happens if not used: Misconfigured or missing Referrer-Policy headers can result in the unintended exposure of sensitive data via the Referer header, such as paths and query strings containing authentication tokens or user data.

Strict-Transport-Security (HSTS)

The Strict-Transport-Security header enforces the use of HTTPS for all future requests to your website.

Recommendation: Strict-Transport-Security: max-age=63072000; includeSubDomains; preload
Usage: By enforcing HTTPS, the Strict-Transport-Security header ensures that the browser never sends insecure requests to your domain, even if the user types http://. The preload directive allows browsers to preload your domain as HTTPS-only.
What happens if not used: Without HSTS, attackers can perform MITM attacks by forcing insecure connections over HTTP, compromising sensitive data such as passwords and session tokens.

Expect-CT

The Expect-CT header enables enforcement and monitoring of Certificate Transparency. It helps in detecting and preventing the use of unauthorized or rogue certificates.

Recommendation: Not recommended unless your site is being used for Certificate Transparency logging.
Usage: When enforced, browsers will refuse connections to a site if the certificate is not published in a publicly trusted log.
What happens if misconfigured: While it offers protection against unauthorized certificates, it may create issues if your site is not correctly configured for Certificate Transparency.

Content-Security-Policy (CSP)

The Content-Security-Policy header helps mitigate XSS, clickjacking, and other code injection attacks by specifying trusted sources for content.

Recommendation: Content-Security-Policy: default-src 'self'
Usage: The default-src 'self' setting restricts all content (scripts, images, stylesheets, etc.) to be loaded only from the same origin. You can customize this to allow trusted external domains.
What happens if not used: Without CSP, attackers can more easily inject malicious scripts into your website or manipulate how your page is rendered.

Access-Control-Allow-Origin

This header specifies which origins are allowed to access your web application’s resources via CORS (Cross-Origin Resource Sharing).

Recommendation: Access-Control-Allow-Origin: https://yoursite.com
Usage: This ensures that only specific, trusted origins can access your resources.
What happens if misconfigured: Setting this header to * can allow any domain to access your resources, potentially leading to data theft and other security risks. Without CORS policies, cross-origin requests might be blocked entirely, disrupting your web services.

Cross-Origin-Opener-Policy (COOP)

The Cross-Origin-Opener-Policy header ensures that your site isolates itself from other origins. This helps prevent certain types of side-channel attacks and data leaks.

Recommendation: Cross-Origin-Opener-Policy: same-origin
Usage: Setting COOP to same-origin ensures that the window or worker opened by your site will only interact with documents from the same origin.
What happens if not used: Without COOP, your site could be vulnerable to cross-origin attacks that exploit the browser's shared resources, allowing attackers to steal data or tamper with your application.

Cross-Origin-Embedder-Policy (COEP)

The Cross-Origin-Embedder-Policy header ensures that a document or worker will only load resources that are explicitly allowed to be cross-origin.

Recommendation: Cross-Origin-Embedder-Policy: require-corp
Usage: Setting COEP to require-corp forces the page to only load cross-origin resources if they explicitly allow it by setting the Cross-Origin-Resource-Policy header.
What happens if not used: Without COEP, cross-origin resources could be embedded without restriction, making your site vulnerable to cross-origin data leaks and potential exploitation of cross-origin workers.

Cross-Origin-Resource-Policy (CORP)

This header restricts which origins can access the resources of your site.

Recommendation: Cross-Origin-Resource-Policy: same-site
Usage: same-site ensures that only requests from the same site (same origin) are allowed to access resources.
What happens if not used: Without this header, your resources can be accessed by any origin, potentially leading to data leakage or exploitation through malicious cross-origin requests.

Permissions-Policy (formerly Feature-Policy)

The Permissions-Policy header controls access to browser features such as geolocation, camera, microphone, etc.

Recommendation: Permissions-Policy: geolocation=(), camera=(), microphone=()
Usage: This setting disables access to certain features like geolocation, camera, and microphone, unless explicitly allowed.
What happens if not used: If this header is not configured, your website could unknowingly allow access to sensitive hardware features, which could be exploited by malicious scripts.

FLoC (Federated Learning of Cohorts)

FLoC is a new web tracking technology developed by Google that groups users into cohorts based on browsing behavior. The Permissions-Policy header can be used to opt-out of FLoC.

Recommendation: Permissions-Policy: interest-cohort=()
Usage: This configuration prevents your site from contributing to FLoC’s tracking mechanism, which can protect user privacy.
What happens if not used: By not opting out of FLoC, your site may participate in behavioral tracking, which could lead to privacy concerns for your users.

Server

The Server header reveals information about the web server being used (e.g., Apache, Nginx, etc.).

Recommendation: Remove this header or set it to a non-informative value.
Usage: By removing the Server header, you prevent attackers from knowing which server you are using, reducing the likelihood of targeted attacks.
What happens if not removed: If this header is present, attackers can identify the web server and potentially exploit known vulnerabilities associated with it.

X-Powered-By

This header discloses information about the technologies powering your web application (e.g., PHP, ASP.NET).

Recommendation: Remove all X-Powered-By headers.
Usage: Removing this header hides unnecessary information about your stack from potential attackers.
What happens if not removed: If this header is present, attackers can gain insights into your tech stack and potentially exploit any known vulnerabilities.

X-AspNet-Version

This header reveals the version of ASP.NET used by the server.

Recommendation: Disable sending this header. Add the following line in your web.config file in the <system.web> section to remove it: <httpRuntime enableVersionHeader="false" />.
Usage: Disabling this header ensures that version-specific information about ASP.NET is not disclosed.
What happens if not removed: Exposing your ASP.NET version could allow attackers to target known vulnerabilities in that specific version.

X-AspNetMvc-Version

This header reveals the version of ASP.NET MVC being used by the application.

Recommendation: Disable sending this header. Add the following line in the Global.asax file to remove it: MvcHandler.DisableMvcResponseHeader = true;.
Usage: Disabling this header helps obscure your tech stack from potential attackers.
What happens if not removed: Exposing the version of ASP.NET MVC can help attackers tailor their attacks based on known vulnerabilities in that version.

X-DNS-Prefetch-Control

This header controls whether or not DNS prefetching is allowed, which can help reduce latency for external resources.

Recommendation: X-DNS-Prefetch-Control: off
Usage: Turning DNS prefetching off ensures that your application is not unnecessarily resolving DNS queries, which can expose it to privacy issues and performance concerns.
What happens if not used: If DNS prefetching is not controlled, browsers might resolve domains preemptively, which can lead to increased privacy risks and data leakage.

Public-Key-Pins (HPKP)

The Public-Key-Pins header was designed to prevent MITM attacks by ensuring that browsers only accept a specific set of public keys for HTTPS connections. However, it has been deprecated due to high implementation risks.

Recommendation: Do not use this header. Instead, enforce security via HSTS and certificate transparency.

Conclusion

Securing web applications requires a multi-faceted approach, and one of the most effective ways to mitigate potential vulnerabilities is by implementing HTTP security headers. By adding and correctly configuring these headers, you can protect your application from common attacks like clickjacking, XSS, and cross-origin vulnerabilities.

Not implementing or misconfiguring these headers can expose your application to unnecessary risks, leaving it vulnerable to a wide array of attacks. Each of these headers has a specific function in protecting the integrity of your web application and ensuring the safety of your users' data. As web security becomes increasingly complex, these headers play a critical role in maintaining a robust defense against potential threats.

Incorporate these headers into your web application’s response, regularly review their configuration, and keep abreast of new developments in web security to ensure that your application remains secure and trusted by users. If you need assistance in setting up and configuring the right HTTP security headers for your application, let Playful Sparkle help you fortify your web security and protect your users' data effectively.

References

Autor článku Zsolt Oroszlány

Vedúci kreatívnej agentúry Playful Sparkle, prináša viac ako 20 rokov skúseností v oblasti grafického dizajnu a programovania. Vedie inovatívne projekty a vo voľnom čase rád cvičí, pozerá filmy a experimentuje s novými funkciami CSS. Zsoltova oddanosť svojej práci a záľubám poháňa jeho úspech v kreatívnom priemysle.