SAML SSO Vulnerabilities: What Bug Bounty Hunters Should Test
SAML remains widely used for enterprise single sign-on. Bugs here often mean account takeover across an entire company tenant — which is why hunters and programs still prioritize SSO carefully.
Only test tenants and IdPs you are authorized to use. Prefer dedicated staging IdPs and test users.
Understand the moving parts
A typical flow involves:
- Service provider (SP) — the app you are testing
- Identity provider (IdP) — Okta, Azure AD, Google, etc.
- SAML Response / Assertion carrying identity claims
- Signature and encryption protecting those claims
- ACS URL where the SP consumes the assertion
Map which values the SP trusts: NameID, email, groups, and custom attributes.
High-value test ideas
Signature validation: If the SP accepts an assertion with a broken or removed signature in a lab IdP setup, that is critical. In production programs, follow rules — many forbid tampering with real IdP traffic. Use the program's SSO test tenant when provided.
Algorithm / wrapping issues: Some parsers check a signature on one node but trust another. Classic XML signature wrapping belongs in advanced lab work with your own SP/IdP pair.
Account linking: After SSO, can you attach an IdP identity to an account that only matches on email? What if the email is unverified at the IdP? Two-account linking tests are usually in-bounds and high impact.
ACS and Recipient: Confirm the assertion is intended for this SP. Mis-routed assertions should fail closed.
Replay: Assertions should be single-use within a short window. Replaying your own assertion after logout should fail.
Practical in-scope workflow
- Configure SSO with a test IdP the program allows.
- Capture a successful login and list trusted claims.
- Change one claim at a time in a controlled lab, or test linking/email confusion on the SP side without forging IdP signatures if forging is disallowed.
- Document whether the SP session becomes another test user.
Many real payouts are SP-side logic bugs (linking, domain allowlists, JIT provisioning) rather than breaking cryptography.
Reporting
Explain whether the flaw is SP or IdP, the exact claim trusted, and the resulting account. Include sanitized SAML (remove signatures/secrets) and a diagram of the flow. Note tenant isolation impact.
Defensive checklist
- Validate signatures with a maintained XML stack and pinned certificates.
- Enforce audience, recipient, destination, and time window checks.
- Treat email as an identifier only when verified and domain-allowlisted.
- Require reauthentication before linking IdP identities.
- Disable insecure legacy bindings in production.
SAML testing rewards methodical identity modeling. Search traffic for “SAML SSO vulnerability” stays high because one broken assertion check can open every seat in a tenant.
Original Bugflare guide informed by PortSwigger SAML security material.