ASVS 5.0 V3.1.1 requires that your documentation states which security features browsers must support to use the application, such as HTTPS, HSTS and Content Security Policy, and defines how the application behaves when a feature is unavailable. It is a Level 3 requirement.
Why it matters
Your protections against XSS, clickjacking and downgrade attacks depend on the browser doing its part. If an old browser ignores your CSP, the control silently does nothing. Without a written decision, nobody knows whether that user should be warned, limited, or blocked.
How to implement it
Add a short browser security section to your design documentation.
| Feature | Required for | If unsupported |
|---|---|---|
| HTTPS | All pages | Redirect to HTTPS, refuse to serve |
| HSTS | All pages | Warn in admin console, log |
| CSP | Account and payment pages | Block sign in with a clear notice |
| SameSite cookies | Session | Require a minimum supported browser version |
Set a minimum browser support policy and review it each release. For blocking decisions, implement a simple server side check using the User-Agent as a hint only, plus feature detection on the client.
How to test it
Open the application in the oldest browser you claim to support and in one you do not. The behaviour should match the table. Confirm the response headers named in the document are actually sent.
Keep it testable
Phrase each row as a behaviour a tester can check, and list the exact header names and values you send. Put the document next to your deployment configuration, so a change to the headers also changes the doc. Review it when your browser support policy changes.
Common mistakes
- Listing features in the docs but never testing the fallback.
- Treating the User-Agent as proof of capability.
Quick check
Do we have to block unsupported browsers?
No. The requirement is to decide and document the behaviour. A warning can be a valid choice.
