The X-Frame-Options header controls whether a webpage can be embedded within <frame>, <iframe>, <embed>, or <object> elements, protecting against clickjacking attacks.

• Configuration Parameters

X-Frame-Options: <Policy>

– DENY → Prevents the page from being embedded in any context.

– SAMEORIGIN → Allows embedding only within the same origin.

– ALLOW-FROM origin → Permits embedding only from a specified origin (deprecated).

• Configuration Recommendations

1. Use DENY for sensitive pages that do not require embedding (e.g., login pages).

2. For basic protection, use SAMEORIGIN, but ensure proper mitigation of XSS attacks on same-origin sites.

3. ALLOW-FROM origin is deprecated—use the CSP frame-ancestors directive instead. For legacy browser support, both can be applied together.

• Configuration Examples

X-Frame-Options: DENY
X-Frame-Options: SAMEORIGIN

The X-XSS-Protection header controls the browser’s built-in Cross-Site Scripting (XSS) filter, blocking malicious XSS attack requests.

• Configuration Parameters

X-XSS-Protection: <Policy>

– 0; → Disables XSS filtering.

– 1; → Enables XSS filtering; removes malicious content while rendering the page.

– 1; mode=block → Enables XSS filtering; blocks page loading if an XSS attack is detected.

– 1; report=<reporting-uri> → Enables XSS filtering; removes malicious content, renders the page, and reports violations to the specified URL.

• Configuration Recommendations

1. Modern browsers have deprecated this header—use Content Security Policy (CSP) for XSS protection instead (X-XSS-Protection: 0).

2. For legacy system compatibility, use: X-XSS-Protection: 1; mode=block.

• Configuration Examples

X-XSS-Protection: 1; mode=block

The X-Content-Type-Options forces browsers to strictly follow the server-declared Content-Type, preventing MIME type sniffing attacks.

• Configuration Parameters

X-Content-Type-Options: <Policy>

– nosniff → Enforces strict validation of the Content-Type. If the MIME type does not match the expected type, the request is blocked.

• Configuration Recommendations

1.Ensure the server correctly sets the Content-Type header before enabling this option to prevent resource loading failures.

2.Enable nosniff site-wide and progressively deploy it from core content to all resources once resource types are verified.

• Configuration Examples

X-Content-Type-Options: nosniff

CSP enforces a whitelist-based mechanism to control the sources from which web pages can load resources, mitigating Cross-Site Scripting (XSS) attacks.

• Configuration Parameters

Content-Security-Policy:<Policy>

– default-src → Defines the default loading policy for all resource types.

– script-src → Controls the allowed sources for JavaScript execution.

– style-src → Defines the allowed sources for CSS stylesheets.

– img-src → Restricts the sources of image resources.

– connect-src → Specifies permitted sources for connections such as XHR, WebSockets, and fetch API requests.

– Policy options: ‘none’ (deny all), ‘self’ (same origin), ‘unsafe-inline’ (allow inline scripts), etc.

• Configuration Recommendations

1. Follow the principle of least privilege – start with default-src ‘none’ and allow only necessary resource types.

2. Remove high-risk options, such as ‘unsafe-inline’ and ‘unsafe-eval’, in production.

3. Use nonce or hash values to replace inline scripts/styles instead of allowing unsafe inline execution.

4. Enable report mode (Content-Security-Policy-Report-Only) first to monitor policy impact before enforcing it.

• Configuration Examples

Content-Security-Policy:
default-src ‘none’;
script-src ‘self’ static.example.com;
style-src ‘self’;
img-src ‘self’ data:;
connect-src ‘self’ api.example.com;