ASVS 5.0 V4.1.4: Allow Only the HTTP Methods You Use
Every route should accept an explicit list of HTTP methods and reject the rest with 405. Here is how to set it up and prove it works.
Deep dives, practical guides, and incident analyses from engineers who build Safeguard. No fluff, no vendor FUD — just what you need to ship secure software.
Every route should accept an explicit list of HTTP methods and reject the rest with 405. Here is how to set it up and prove it works.
Headers like X-Forwarded-For and X-User-ID set by a proxy must not be forgeable by clients. Strip them at the edge and trust only your own hops.
Only endpoints meant for browsers should redirect HTTP to HTTPS. API endpoints should refuse plain HTTP so a misconfigured client fails loudly.
ASVS V4.1.1 (Level 1): every response with a body needs a Content-Type that matches the content, with a charset for text, XML and similar types. Config and tests.
ASVS V3.7.5 (Level 3) says the app must behave as documented, by warning or blocking, when a browser lacks expected security features. Detection code and test steps.
ASVS V3.7.4 (Level 3) requires your top-level domain on the HSTS preload list so browsers enforce TLS from the first visit. Prerequisites, header, submission and removal risks.
ASVS V3.7.3 (Level 3) wants a notification, with a way to cancel, when a user is redirected to a URL outside your control. Interstitial design, code and tests.
ASVS V3.7.2 (Level 2): automatic redirects to hosts you do not control must hit an allowlist. Open redirect examples, safe code for Express and Django, and tests.
ASVS V3.7.1 (Level 2) bans client-side technologies that are unsupported or insecure, such as Flash, ActiveX and Java applets. How to find leftovers and replace them.
Weekly insights on software supply chain security, delivered to your inbox.
Your first fix PR is minutes away.
No sales call required, even your agent can complete the purchase over MCP.