Configuring specific HTTP security headers can prevent otherwise successful Cross-Site Scripting (XSS) attacks. However, outdated advice on these headers is prevalent in the security community because many vulnerability scanners and penetration test reports do not reflect current standards.

Below are the HTTP security header best practices for 2024.
Simple Summary: Focus on Content-Security-Policy and use https://content-security-policy.com/ https://csp.withgoogle.com/docs/faq.html#static-content

Prioritize Content-Security-Policy

The primary focus should be to correctly add a Content-Security-Policy HTTP header. This process appears to be straightforward, but depending on what scripts your site is currently using, it can take some time to troubleshoot and refactor the site.

The following starter CDP header configuration is a good starting point for many sites:

Content-Security-Policy: default-src 'none'; script-src 'self'; connect-src 'self'; img-src 'self'; style-src 'self';base-uri 'self';form-action 'self'

This Content Security Policy Reference can be helpful when deciding how to proceed with CSP configuration. In general, searching “How to set a header on [your-server-type]” should bring up the current methods for add headers.

A common misconfiguration with CSP HTTP Headers is allowing scripts from cloud providers or third-party CDNs where developers host static files (e.g. AWS S3 buckets, Azure Blob Storage, and Google’s user content). Configuring a CSP to allow scripts from locations like amazonaws.com, *.blob.core.windows.net, and googleusercontent.com leave the endpoint vulnerable since attackers can load their payloads from those locations as well.

Hashing inline scripts can be done with Report-URI’s Script and Style Hasher. Do not include <script> tags in the hash.

Sources:

• OWASP’s Cheat Sheet: https://cheatsheetseries.owasp.org/cheatsheets/Content_Security_Policy_Cheat_Sheet.html
• Reference and CSP checker: https://content-security-policy.com/
• A list of example CSP policies: https://content-security-policy.com/examples/
• Mozilla’s CSP Source values, complete list, and descriptions: https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Security-Policy/Sources
• Report-URI’s Script and Style Hasher: https://report-uri.com/home/hash

Add X-Content-Type-Options

In general, set the header X-Content-Type-Options: nosniff. The nosniff value prevents browsers from getting creative when rendering pages and causes them to follow the set type.

Source: Mozilla’s documentation: https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/X-Content-Type-Options

Add Strict-Transport-Security

• Strict-Transport-Security: max-age=63072000; includeSubDomains; preload Source https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Strict-Transport-Security

Ignore or Remove X-XSS-Protection (Depreciated)

Many vulnerability scanners and penetration testers still recommend implementing an X-XSS-Protection header. This header is depreciated and can introduce issues (see Mozilla’s statement on the subject).

Ignore or Remove X-Frame-Options (Depreciated)

A properly implemented Content Security Policy header contains `frame-ancestors and prevents Clickjacking, making this header obsolete.

The HTTP header X-Frame-Options was designed to prevent an attack called clickjacking or UI Readdress where an attacker attempts to trick users into clicking by layering transparent layers.
Sources

• OWASP’s Clickjacking Cheat Sheet: https://cheatsheetseries.owasp.org/cheatsheets/Clickjacking_Defense_Cheat_Sheet.html
• Mozilla’s Official Documentation: https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Security-Policy/frame-ancestors