JWT “none”-algorithm bypass
The JWT implementation accepted tokens signed with the “none” algorithm: an unsigned token was a valid token. Practical effect: any user could be impersonated, including administrators, by crafting a token by hand.
Case Study / Web application VAPT
JWT “none”-algorithm bypass, and the chain behind it
Survey responses are quietly sensitive: strategy, staffing, customer complaints, all sitting in one place. A fast-growing survey platform had scaled well past the last serious look at its security, and engaged us for an end-to-end vulnerability assessment and penetration test to learn what an attacker would find first. The answer turned out to be an unsigned token that opened every account.
Fast-growing SaaS survey platform · Middle East
What we found
Publicly accessible S3 bucket
User-uploaded files lived in a world-readable Amazon S3 bucket. Anyone with the bucket name could enumerate and download customer uploads, no authentication involved.
Role-based access control gaps
Privilege checks were inconsistently enforced across endpoints; lower-privileged users could reach restricted functionality directly.
Unrestricted file upload
Uploads were accepted without sufficient content validation, opening a path for hostile files to enter the platform.
How the engagement ran
OWASP-aligned manual testing
Full web-application assessment following the OWASP Top 10 methodology, with manual testing for the logic and chaining that scanners can't reason about.
Controlled exploitation
Each critical finding was demonstrated in a controlled way, so severity discussions were about evidence, not opinion.
Chained impact analysis
Findings were presented as attack chains (public bucket + token forgery + RBAC gaps = full data access) and translated into business consequences: financial, reputational, regulatory.
Developer-level remediation
Fix guidance written for the engineers who would implement it, plus secure-coding workshops for the team.
Technologies & methods
- OWASP Top 10 methodology
- Manual testing and controlled exploitation
- JWT implementation review
- Amazon S3 permission analysis
- Attack-chain impact analysis
- Secure-coding workshops
What changed
- Critical findings, including the authentication bypass and public bucket, were remediated and verified on retest.
- The engineering team took away concrete secure-coding practices along with the report.
- The engagement established the security baseline the platform now builds on.
Client identity is confidential by agreement. The engagement is published anonymized; we never publish metrics we didn't measure.
What this engagement taught us
Unsigned JWTs still ship in 2026, and every one of them is a master key waiting for someone to read the algorithm header. Just as durable a lesson: no single finding here was exotic. The danger lived in the chain, which is why we present findings as attack paths instead of a flat list.
Ready to scope the work?
A 30-minute call with the engineers who will do the testing, not a sales gate.