JSON Web Tokens have become the de facto standard for authentication and authorization in modern applications. However, their apparent simplicity hides multiple vulnerabilities that, if properly exploited, can completely compromise a system's security. At Q2BSTUDIO, a company specialized in custom software, we have audited dozens of projects where JWT implementation had critical flaws, often overlooked even by experienced teams. This article analyzes three classic attack vectors and, most importantly, reveals the single defensive rule that blocks them all. Additionally, we will see how this rule integrates naturally into cloud architectures (AWS/Azure), BI solutions with Power BI, and systems with AI agents.
Before diving in, it is worth recalling that a JWT consists of three base64url-encoded parts: the header, the payload, and the signature. The header specifies the algorithm used for signing; the payload contains the claims (such as user role); and the signature is computed over the first two parts. Anyone holding the token can read the payload because it is only encoded, not encrypted. This fact, combined with verification being delegated to the token itself, gives rise to the attacks described below.
Attack 1: 'none' algorithmThe first attack is almost insulting in its simplicity. If the server trusts the algorithm declared in the header, an attacker can modify the token to say 'alg':'none', alter the payload with admin privileges, and remove the signature. The server, if it does not explicitly validate that the algorithm is secure, will accept the token as authentic. This flaw, documented in CVE-2015-9235 for the Node.js jsonwebtoken library, affected many default implementations. In cybersecurity projects we have reviewed at Q2BSTUDIO, we found that even teams using modern frameworks forgot to configure an allowlist of algorithms, leaving the door open to this vector.
Attack 2: Weak secret (offline brute force)HS256, HS384, and HS512 algorithms use HMAC with a shared secret key. If that key has been chosen by a human (like 'secret' or 'changeme'), an attacker can download a dictionary like rockyou.txt and try each candidate against the original token, without interacting with the server. There is no rate limit or account lockout. Once the key is found, the attacker can sign any token. The solution is to use keys generated by a cryptographically secure pseudorandom number generator (CSPRNG) of at least 256 bits. In the cloud (AWS/Azure) solutions we develop at Q2BSTUDIO, we recommend storing these keys in managed services like AWS Secrets Manager or Azure Key Vault, and rotating them periodically.
Attack 3: Algorithm confusion (RS256 to HS256)This attack is more sophisticated and exploits that the server trusts the algorithm in the header. If the server uses RS256 (asymmetric signing with private key and verification with public key), the attacker changes the algorithm to HS256. Then the server will use the public key (which is, by definition, public) as the HMAC key to verify. The attacker downloads that public key, signs a fake token with HS256 using the public key bytes as the secret, and the server accepts it. A subtle detail: trailing newlines in the PEM file can change the result. Therefore, when auditing tokens, it is important to test variants. At Q2BSTUDIO, when we implement systems with AI agents that exchange tokens between microservices, we ensure that verification does not delegate algorithm choice to the incoming token.
The one rule that stops them allAll three attacks share the same root: trusting the token's own data to decide how to verify it. The solution is simple and implemented in one line of code: fix on the server an allowlist of accepted algorithms and reject any other, including 'none'. For example:
ALLOWED = {'RS256'}claims = jwt.decode(token, public_key, algorithms=list(ALLOWED))
That single algorithms argument eliminates the 'none' algorithm attack and the RS/HS confusion attack at once. Combined with a robust secret key (for HS256) or a well-managed asymmetric key pair, the third door is closed. Additionally, set short expirations, avoid including sensitive data in the payload (remember it is only encoded), and periodically audit tokens in production.
At Q2BSTUDIO, we apply this rule in all our developments, whether in custom software, in BI solutions with Power BI that authenticate via tokens, or in cloud architectures with AWS or Azure where services communicate using JWTs. Security culture is not an add-on but a design pillar. Our cybersecurity teams perform token audits as an integral part of the pentesting process, and we train developers not to rely on default configurations.
We recommend any organization using JWTs to review their tokens with tools like jwt-auditor (open source and offline). Just run jwt-auditor audit <token> to detect if the algorithm is insecure, if the key is guessable, or if the token verifies with the public key as HMAC. Twenty seconds of checking can save a major security incident.
The described attacks are not new, but they remain effective because many teams assume the token verifies itself. The reality is that the security of a JWT depends entirely on how the server validates it. Adopting the rule of not delegating algorithm choice is the first step toward robust authentication. At Q2BSTUDIO, we help companies build secure systems from the design phase, integrating cybersecurity, artificial intelligence, and cloud coherently. If your organization uses JWTs, do not wait for an attacker to show you how vulnerable they are.
