Web security: find the right guide

What public web configuration can reveal

When a page is requested, your web service returns HTTP response headers alongside its content. Some of these tell the browser how to handle connections, resources or data. What you can initially observe is which values the response you reached contains. Whether a rule suits the application and works in the affected flows requires further context.

A missing header does not yet prove an exploitable vulnerability. Conversely, present headers or a good scanner grade do not establish that a web application is secure overall. Sign-ins, permissions and business flows require their own checks. An HTML page and a response containing only JSON also have different requirements. The MDN practical web security overview explains several measures and where they apply.

HSTS, CSP or cookies: where does your question belong?

These three foundations address different tasks. Choose your starting point according to the specific finding.

• Your question

  Should the browser access a known host only over HTTPS?

  What the mechanism controls

  HSTS stores an HTTPS requirement for a host and, where specified, its subdomains.

  Relevant starting point

  Understand HSTS

  A header sent today and a requirement already stored in the browser are different states. First contact and a distributed preload entry must be considered separately. A missing header does not immediately remove a stored HSTS policy. Before a far-reaching change, establish which hosts are affected and whether HTTPS is available for them. Further reading: understand HSTS preload. Technical basis: RFC 6797, section 8.

• Your question

  Which scripts or resources may a page load or execute?

  What the mechanism controls

  CSP restricts behaviour within a document according to the directives actually in effect.

  Relevant starting point

  Understand Content Security Policy

  An enforced policy can, for example, restrict unwanted script execution; its precise effect depends on its directives and the application. A Content-Security-Policy-Report-Only policy observes violations of that policy but does not enforce it. Any enforced policies present alongside it continue to apply. For a planned change, see introduce CSP gradually and, for dynamic scripts, understand CSP nonces. Technical basis: MDN on CSP and testing a policy.

• Your question

  Under what conditions is a cookie sent or accessible to scripts?

  What the mechanism controls

  Cookie attributes control individual cookie properties; the application still manages the session.

  Relevant starting point

  Understand cookie security

  Secure restricts cookie transmission to secure connections, HttpOnly blocks access through JavaScript cookie APIs, and SameSite controls whether cookies are sent in certain cross-site situations. An observed Set-Cookie header establishes neither all stored cookies nor the behaviour of a complete sign-in. The cookie chapter explains attributes and prefixes and implementation checks. Technical basis: MDN on Set-Cookie. Technical cookie attributes do not answer legal questions about consent.

From a finding to a controlled change

1. Identify the finding. Record the URL examined, the host reached, response type, time and specific observation. ‘Not found’, ‘not checked’ and ‘check failed’ are different statements. Read the relevant foundation first.
2. Choose responsibility and guidance. Establish whether the application, web server or an upstream service sets the value. Use the relevant technical foundation and your environment's documentation. An example configuration needs adapting to your application, access permissions and installed versions.
3. Check the response and the function. After a change, check the configuration actually served and the affected functions, such as sign-in, embedded content or payment flows. Another public check can supplement this; it does not replace browser or application tests. Testing CSP with Report-Only is not a general procedure for HSTS or cookies.

Focused implementation guides

Detailed guides are available for selected tasks. Check their prerequisites and limits before adopting a configuration. When several services are involved, what matters is where the public response is actually changed.

• Configure and check HSTS with Nginx
• Introduce CSP gradually
• Use CSP nonces in dynamic applications

When a finding concerns another topic

Consult these further chapters as needed:

For an organisational or regulatory question, there is also the Compliance overview. A header finding or report is not a complete compliance assessment.

Check public configuration and record findings

In its free beta, the Web Security Check provides a limited snapshot of publicly reachable configuration characteristics. Read the subject of the check, individual findings and measurement limits in the result. Even A+ applies only to the stated scope and time.

If you want to pass a finding to the person responsible or document a change, the report explanations can help. A report file does not extend the scope of the check. Record your own functional tests and open questions separately; another check is a new snapshot.