ASVS 5.0 V10.3.1: Resource Servers Must Check Token Audience
ASVS V10.3.1 (Level 2): an OAuth resource server accepts only access tokens issued for it, checked via the aud claim or token introspection.
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.
ASVS V10.3.1 (Level 2): an OAuth resource server accepts only access tokens issued for it, checked via the aud claim or token introspection.
ASVS V10.2.3 (Level 3): an OAuth client asks for the narrowest scopes and authorization parameters it needs. How to audit and trim them.
ASVS V10.2.2 (Level 2): clients that talk to several authorization servers must stop mix-up attacks by validating the iss value in responses.
ASVS V10.2.1 (Level 2): an OAuth client using the code flow must defend against login CSRF with PKCE or a checked state parameter. Code and test steps.
ASVS V10.1.2 (Level 2): accept authorization responses only for flows this browser session started. Use unguessable state, nonce and PKCE verifier bound to the session.
ASVS V10.1.1 (Level 2): keep access and refresh tokens away from components that do not need them. Use a backend for frontend so the browser never holds them.
ASVS 5.0 V1.5.3 (Level 3) requires every parser of one data type to behave the same, with one character encoding. Avoid JSON and URL parser mismatches.
ASVS 5.0 V1.5.2 (Level 2) forbids insecure deserializers on untrusted input and requires type allowlists. Java and Python examples plus a test plan.
ASVS 5.0 V1.5.1 (Level 1) requires restrictive XML parser settings with external entities off. Config for Java, Python and .NET, and a payload to test with.
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.