ASVS 5.0 requirement V3.7.5 says the application must behave as documented, for example warn the user or block access, when the browser used to reach it does not support the security features the app expects. It is a Level 3 requirement.
Why it matters
Your security design may assume things like SameSite cookies, CSP enforcement, Sec-Fetch headers, Web Crypto or WebAuthn. An old or unusual browser ignores unknown headers without complaint, so protections quietly vanish. If nobody decided what should happen, the behavior is accidental.
How to implement it
First, write down the features you rely on and what you do when they are missing: warn, degrade or block. Then detect on the client:
const missing = [];
if (!window.crypto || !window.crypto.subtle) missing.push("Web Crypto");
if (!("PublicKeyCredential" in window)) missing.push("WebAuthn");
if (!window.CSS || !CSS.supports("selector(:is(a))")) missing.push("modern CSS");
if (missing.length) {
document.body.innerHTML = "";
const p = document.createElement("p");
p.textContent = "This browser lacks required security features: " + missing.join(", ") + ". Please update it.";
document.body.appendChild(p);
}
For server side checks, treat a missing Sec-Fetch-Site header on sensitive routes according to your documented rule, see V3.5.3. Keep the message in plain text and avoid inserting user supplied data.
How to test it
Run the app in the oldest browser you claim to support and in one older than that, and check the behavior matches the document. Remove features in a test build, for example by deleting window.PublicKeyCredential in the console before load, and confirm the warning or block appears.
Common mistakes
No written decision. The requirement asks for documented behavior.
Silent fallback to weaker protection.
Detection by user agent string. Test the feature itself.
Quick check
Must I block unsupported browsers?
No. Warning is acceptable if that is what you documented and it fits the risk.
Sources
- OWASP ASVS 5.0, requirement V3.7.5
