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.
For Level 3, require pushed authorization requests whenever the authorization code grant is used, so request parameters never travel through the browser.
At Level 3, the authorization server should validate response_mode per client or use PAR or JAR so the value cannot be tampered with.
Register each OAuth client with the narrowest scope list it requires and clamp requests to it. A short guide to configuring and checking scope assignment.
Token, PAR and revocation requests from a confidential client must carry client authentication. Configure it, keep secrets out of repos, and test the rejection.
ASVS V10.4.1 (Level 1): the authorization server validates redirect URIs against a pre-registered per-client allowlist using exact string comparison.
ASVS V10.3.5 (Level 3): make stolen access tokens useless by requiring sender-constrained tokens with DPoP or mutual TLS. How it works and how to test it.
ASVS V10.3.4 (Level 2): when an API needs strong or recent authentication, check acr, amr and auth_time in the token instead of assuming them.
ASVS V10.3.3 (Level 2): when a decision needs a unique user, use claims that cannot be reassigned, typically iss plus sub, never email or username.
ASVS V10.3.2 (Level 2): the resource server must use delegated authorization claims (scope, sub, authorization_details) when deciding access, not only token validity.
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.
