WebOTG-SM-010 — Missing Security Headers

01 / OBJECTIVE

Objective

What are we verifying?

Verify that HTTP responses contain the security controls required by the application's threat model and deployment architecture, and that those controls are configured consistently and effectively.

Security response headers allow an application to communicate security-related policies to user agents. Incorrect or missing headers can weaken browser-side protections and may increase the impact of other vulnerabilities.

This procedure focuses on the presence, syntax, applicability and effective behavior of security headers. A header should not be added merely because it appears in a generic checklist; its value and policy must match the application's requirements.

Header presence alone does not establish security

A security header with an ineffective value can provide little or no protection. Verification must evaluate the actual policy delivered to the browser and whether it is appropriate for the application.

02 / SCOPE

Scope

Review security-related HTTP responses for:

Public HTML pages

Authenticated application pages

Authentication endpoints

API responses where browser access is relevant

Redirect responses

Error responses

Static resources where applicable

Reverse proxy and web-server generated responses

03 / PREREQUISITES

Prerequisites

Authorization	Confirm authorization to inspect and test HTTP responses.
Application scope	Identify domains, subdomains and application endpoints included in the assessment.
Architecture	Determine whether headers are generated by the application, web server, CDN, load balancer or reverse proxy.
Browser baseline	Use a current standards-compliant browser or equivalent HTTP inspection capability where appropriate.

04 / METHODOLOGY

Methodology

Inspect representative responses from the application's major response classes. Compare the delivered policies against the application's security requirements and deployment architecture.

Method	Purpose
HTTP response inspection	Identify security-related response headers and their values.
Configuration review	Determine where and how headers are generated and maintained.
Browser behavior validation	Confirm that relevant browser policies are interpreted as intended.
Response consistency review	Determine whether security policies are consistently delivered across applicable response types.

05 / PROCEDURE

Test procedure

01

Identify response classes Select representative HTML, authenticated, redirect, error and other applicable responses.

02

Capture HTTP response headers Inspect the complete response header set without exposing sensitive session information.

03

Identify applicable security controls Determine which security headers are appropriate for the application's architecture and threat model.

04

Evaluate policy values Review whether header values provide meaningful protection and do not contain unnecessarily broad or contradictory directives.

05

Check response consistency Verify that applicable policies are not accidentally omitted from important response paths.

06

Validate browser behavior Confirm relevant policies are recognized and behave as intended in supported user agents.

06 / HEADER CONTROLS

Security header controls

Header / control	Review objective
Content-Security-Policy	Review whether the application defines an appropriate browser content policy for scripts, styles, frames, images, connections and other applicable resources.
Strict-Transport-Security	Where HTTPS is required, verify that transport security is configured appropriately for the deployment.
X-Content-Type-Options	Review protection against MIME-type sniffing where applicable.
Referrer-Policy	Verify that referrer information is restricted according to privacy and application requirements.
Permissions-Policy	Review browser feature permissions that should be restricted by the application.
Frame-ancestors / framing controls	Verify that pages cannot be embedded by unauthorized origins where framing is not required.
Cookie security attributes	Review Secure, HttpOnly and SameSite attributes for security-sensitive cookies.

Example response review

Illustrative HTTP response EXAMPLE

HTTP/1.1 200 OK
Content-Type: text/html; charset=UTF-8

Content-Security-Policy: [application policy]
Strict-Transport-Security: [approved policy]
X-Content-Type-Options: nosniff
Referrer-Policy: [approved policy]
Permissions-Policy: [approved policy]

The values above are intentionally represented as placeholders. A professional assessment should not blindly copy a generic policy into every application. Policy directives must be selected according to actual application functionality.

Avoid breaking security controls with permissive policies

A policy that allows broad script, frame or resource sources merely to eliminate browser errors may weaken the intended security control. Remediation should preserve application functionality while minimizing unnecessary trust.

07 / ASSESSMENT

Assessment

Condition	Assessment consideration
Appropriate policy present	Record as implemented when the policy is applicable and effective.
Header absent	Determine whether the missing control represents a meaningful security weakness for the application.
Header present but ineffective	Assess the actual policy rather than giving credit solely for header presence.
Header conflicts with application	Review whether the policy is incorrectly configured or creates an operational exception.
Policy varies unexpectedly	Investigate inconsistent response handling across application paths.

08 / EXPECTED RESULT

Expected result

Pass condition

Applicable HTTP security controls are deliberately configured, consistently delivered and aligned with the application's architecture and security requirements.

Security headers should be managed as part of the application's secure configuration rather than being added as an unverified checklist item.

09 / FAILURE CRITERIA

Failure criteria

An applicable security control is missing without documented justification.

A security header exists but its policy is ineffective or unnecessarily permissive.

Security policies are unexpectedly omitted from important application responses.

Configuration at the proxy or web-server layer unintentionally removes application security headers.

Security policy configuration contradicts documented application security requirements.

Example finding SECURITY CONFIGURATION

The application does not deliver an appropriate browser security policy on its primary HTML responses. The deployment documentation identifies browser-side content restrictions as a required security control, but the production response does not implement the documented policy.

10 / REMEDIATION

Remediation

Implement applicable security response headers at the most appropriate control layer and maintain them as part of the application's secure configuration baseline.

Recommended approach

Identify the security requirements applicable to the application.
Determine which headers are generated by the application and which are generated by infrastructure.
Define approved header policies.
Implement the policies in the appropriate layer.
Test the policies against all supported application functionality.
Remove contradictory or obsolete configuration.
Ensure security headers are not accidentally stripped by reverse proxies or CDNs.
Document justified exceptions.
Include header configuration in deployment validation.

Example baseline

Illustrative security baseline EXAMPLE

HTTP Security Baseline

Transport:
    HTTPS required
    HSTS policy approved

Content:
    CSP policy defined
    Frame embedding policy defined

Browser behavior:
    MIME sniffing protection enabled
    Referrer policy defined
    Browser feature permissions reviewed

Cookies:
    Secure attribute reviewed
    HttpOnly attribute reviewed
    SameSite attribute reviewed

Configuration ownership must be explicit

Document whether the application, web server, reverse proxy, CDN or another infrastructure component owns each security header. Multiple layers independently modifying the same policy can create unexpected results.

11 / VERIFICATION

Verification

01

Capture the updated response Inspect the complete HTTP response after remediation.

02

Verify each applicable policy Confirm that the expected headers and approved directives are present.

03

Test representative response classes Check authenticated pages, redirects, errors and other relevant response paths.

04

Validate browser behavior Confirm that the intended browser security behavior occurs without introducing unacceptable application functionality failures.

05

Verify deployment persistence Confirm that the configuration remains active following application restart, redeployment, proxy reload or infrastructure changes.

PASS

Applicable security policies are present, effective and consistently delivered.

FAIL

An applicable security control is absent, ineffective or incorrectly configured.

NOT TESTED

The relevant security policy or response behavior could not be adequately verified.

12 / EVIDENCE

Evidence requirements

Application and environment tested

Response class tested

Relevant HTTP security headers

Effective policy values

Configuration ownership

Before-remediation evidence

Post-remediation response

Browser behavior verification

Final PASS / FAIL determination

Sanitize captured responses

Remove session cookies, authorization tokens, personal information, internal hostnames and other sensitive values before publishing or sharing assessment evidence.

13 / CLASSIFICATION

Classification

WebOTG procedure	WebOTG-SM-010
OWASP category	A02:2025 — Security Misconfiguration
Procedure type	HTTP security configuration review
Assessment result	PASS / FAIL / NOT TESTED
Finding severity	Determine from the affected security control, application context, exploitability and resulting impact.

WebOTG classification notice

WebOTG-SM-010 is a WebOTG-defined verification procedure. The identifier is not an OWASP-defined test identifier.

14 / REFERENCES

References

Source	Relevance
OWASP Top 10:2025 — A02	Security Misconfiguration category.
OWASP Web Security Testing Guide	Web application security testing methodology.
OWASP Application Security Verification Standard	Application security verification requirements related to secure configuration.
HTTP security header specifications	Authoritative definitions and behavior of applicable HTTP response controls.
Application security policy	Organization-specific requirements for transport security, browser controls and application configuration.

WebOTG should maintain official source URLs, source versions and review dates through its content-management system so references can be updated independently of the procedure template.