WebOTG Security Testing Library ● Public reference
W WebOTG
Search
WebOTG
Standards Countries Topics Resources About
WEBOTG SECURITY TESTING PROCEDURE

WebOTG-SM-003 — Security Headers Configuration

A structured procedure for reviewing HTTP response headers that provide browser-enforced security controls and reduce unnecessary exposure of web applications.

WebOTG ID SM-003 OWASP A02:2025 Type Security Control Review Method HTTP / Configuration Version 1.0
01 / OBJECTIVE

Objective

What are we verifying?

Verify that HTTP security controls appropriate to the application's architecture are correctly implemented and that response headers do not unnecessarily expose platform information.

Security-related HTTP response headers allow an application or web server to communicate security policies to capable user agents.

This procedure focuses on verifying the effective HTTP response behavior. The presence of a header alone is not sufficient to determine whether the associated security control is correctly configured.

02 / SCOPE

Scope

Review security-relevant response headers applicable to the target application.

Content-Security-Policy

Defines browser-enforced restrictions on content sources and execution contexts.

Strict-Transport-Security

Instructs supporting browsers to use HTTPS for the applicable host.

X-Content-Type-Options

Helps prevent MIME-type sniffing when configured appropriately.

Referrer-Policy

Controls the amount of referrer information sent with requests.

Permissions-Policy

Controls access to supported browser features according to application requirements.

Set-Cookie

Session and authentication cookies should use appropriate security attributes.

Server / X-Powered-By

Review unnecessary technology disclosure in response headers.

Cache-Control

Review caching behavior for responses containing sensitive information.

Header applicability depends on architecture

Do not require every header on every application. Security controls should be selected according to the application's functionality, browser behavior, authentication model and deployment architecture.

03 / PREREQUISITES

Prerequisites

Authorization Confirm authorization to assess the target application.
HTTPS configuration Determine whether HTTPS is required for the application.
Application architecture Understand the frontend, APIs, authentication mechanisms and third-party integrations.
Browser compatibility Identify any legitimate browser requirements that affect policy design.
04 / METHODOLOGY

Methodology

Assess both the declared configuration and the effective response received by a client.

Method Purpose
HTTP response inspection Identify headers actually returned by the application.
Configuration review Determine where the header policy is defined.
Policy analysis Determine whether the configured policy matches application requirements.
Browser verification Confirm practical behavior where browser-enforced controls are involved.
05 / PROCEDURE

Test procedure

Test representative responses

Review more than the homepage. Security headers can differ between application routes, APIs, authentication endpoints, static resources and error responses.

01
Select representative endpoints Include the homepage, authenticated pages, API responses, authentication endpoints and relevant error responses where applicable.
02
Capture HTTP responses Record response headers and relevant status information without exposing sensitive authentication data.
03
Identify security policies Determine which browser security controls are implemented and whether their values are appropriate for the application.
04
Identify unnecessary disclosure Review response headers for unnecessary disclosure of server, framework or runtime implementation details.
05
Compare responses Compare representative routes to identify inconsistent or missing security controls.
06 / HEADER REVIEW

Header-specific review

Content-Security-Policy

Determine whether a Content Security Policy is appropriate and whether its directives are consistent with the application's actual resource requirements.

Illustrative policy EXAMPLE 
Content-Security-Policy:
default-src 'self';
object-src 'none';
base-uri 'self';

The example is intentionally restrictive and illustrative. Do not copy it blindly into production. A CSP must be designed around the application's legitimate scripts, styles, images, frames and external services.

Strict-Transport-Security

Where HTTPS is consistently deployed and the policy is appropriate for the host, verify that HSTS is configured deliberately.

Illustrative response header EXAMPLE 
Strict-Transport-Security:
max-age=31536000
HSTS requires careful deployment

Do not enable aggressive HSTS settings without understanding the application's domain structure, subdomains and HTTPS readiness. An inappropriate policy can make legitimate services inaccessible.

Additional controls

Control Review question
X-Content-Type-Options Is MIME sniffing protection appropriately configured for relevant responses?
Referrer-Policy Does the policy prevent unnecessary disclosure of URL information?
Permissions-Policy Are unnecessary browser capabilities restricted?
Cookies Are authentication and session cookies appropriately protected with attributes such as Secure, HttpOnly and SameSite?
Technology disclosure Are unnecessary Server or framework identification headers exposed?
Caching Are sensitive responses protected against inappropriate caching?
07 / EXPECTED RESULT

Expected result

Pass condition

Applicable HTTP security controls are intentionally configured, their effective behavior matches the application's security requirements, and unnecessary technology disclosure is minimized.

A missing header should not automatically be classified as a vulnerability. The tester should establish the security requirement, applicability and resulting risk.

08 / FAILURE CRITERIA

Failure criteria

Consider the control ineffective when a confirmed configuration weakness creates a relevant security exposure.

A required security policy is absent without documented justification.
A security policy is present but incorrectly configured for the application's requirements.
Security headers are inconsistently applied to relevant application responses.
Sensitive responses are subject to inappropriate caching behavior.
Authentication or session cookies lack required security attributes.
Response headers unnecessarily expose implementation details that materially increase security exposure.
Example finding REVIEW REQUIRED

A sensitive authenticated response is configured with caching behavior that permits storage where the application's security requirements require the response to remain private.

09 / REMEDIATION

Remediation

Define HTTP security policies centrally where practical, then apply them consistently across the application and supporting infrastructure.

Recommended approach

  1. Establish the security requirements for each application class and response type.
  2. Define the required HTTP security headers.
  3. Configure policies at the most appropriate layer, such as the application, reverse proxy or web server.
  4. Remove unnecessary technology disclosure.
  5. Apply secure cookie attributes to authentication and session cookies.
  6. Protect sensitive responses against inappropriate caching.
  7. Test policy compatibility with legitimate application functionality.
  8. Include header verification in deployment testing.

Example reverse-proxy configuration

Illustrative configuration EXAMPLE 
add_header X-Content-Type-Options "nosniff" always;

add_header Referrer-Policy
    "strict-origin-when-cross-origin" always;

add_header Content-Security-Policy
    "default-src 'self'; object-src 'none';"
    always;

This configuration is illustrative rather than a universal production baseline. Policy values must be reviewed against the actual application architecture.

10 / VERIFICATION

Verification

01
Repeat the original HTTP requests Request the same representative endpoints used during the initial assessment.
02
Compare effective headers Confirm that the intended security headers and values are present in the actual response.
03
Test affected functionality Verify that the new policy does not break legitimate scripts, integrations, authentication or other required application functionality.
04
Check consistency Confirm that applicable controls are consistently enforced across representative routes and response classes.
PASS

Applicable controls are correctly implemented and verified through effective responses.

FAIL

The identified security weakness remains present after remediation.

NOT TESTED

The required response or verification condition could not be evaluated.

11 / EVIDENCE

Evidence requirements

Target application and environment
Endpoint tested
HTTP response status
Relevant response headers
Configuration evidence where authorized
Browser or functional verification where applicable
Remediation evidence
Post-remediation response
Redact sensitive information

Do not publish session identifiers, authorization tokens, private URLs, credentials or other sensitive information in evidence.

12 / CLASSIFICATION

Classification

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

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

13 / REFERENCES

References

Source Relevance
OWASP Top 10:2025 — A02 Security Misconfiguration category.
OWASP Web Security Testing Guide Testing methodology for configuration and deployment controls.
OWASP ASVS Application security verification requirements.
MDN Web Docs Browser behavior and HTTP security header reference.

WebOTG should maintain reference URLs, source versions and review dates centrally through its content-management system. This allows references to be updated without modifying the procedure template.