Tested fixes for CWE-347 in Express, Flask, Spring Boot, ASP.NET Core, Next.js, FastAPI and net/http: the vulnerable code, the fix, a plausible fix that still fails, and the regression tests.
MITRE’s description of CWE-347: The product does not verify, or incorrectly verifies, the cryptographic signature for data.
Common consequences MITRE lists
- Access Control, Integrity, Confidentiality: Gain Privileges or Assume Identity; Modify Application Data; Execute Unauthorized Code or Commands
Signatures are often the only proof that a token, webhook, update or SAML assertion came from a trusted party; a verification gap lets attackers forge identity or ship code.
- Fix the expected algorithms and trusted keys in configuration, and never let the message choose them, for example through a JWT
algorjkuheader. - Verify the signature over the exact bytes you will use, before parsing or acting on the content.
- Reject unsigned and malformed input explicitly, and test that tampered and wrongly signed messages fail.
Guides on this site
JWT validation: algorithms, keys, claims and key rollover
Validate a JWT against a fixed algorithm, trusted keys and the expected issuer, audience and type, reject the known header attacks, and rotate signing keys without accepting arbitrary keys or breaking valid tokens.
Verify webhook deliveries before acting
Verify the provider’s signature over the correct bytes, then apply replay, authorization, and idempotency controls before a business action.
SAML single sign-on: verify signed assertions without losing the identity boundary
Bind a validated SAML assertion to its trusted issuer, the exact signed element, your service, the browser request and a replay record before creating a local session, and keep your SAML library ahead of its advisories.
Verify artifact signatures against an explicit trust policy
Require the expected artifact, signer and release context before allowing a signed package or image to proceed.
Defend JWTs against forgery, confusion and replay
Verify a JWT as an issuer-, type- and audience-bound assertion with an algorithm allowlist and trusted keys, closing the alg "none", key-confusion, header-injection, weak-secret and replay attacks.
Choose cryptographic algorithms and parameters by job
A sourced quick reference for October 2026: which algorithm and parameters to use for encryption, hashing, passwords, MACs, signatures, key agreement, key derivation, randomness and TLS, the matching APIs in Node.js, Python, Java, Go and .NET, and where post-quantum migration stands.
Hash collisions and digital signatures: MD5, SHA-1 and what to use
Distinguish collisions from preimages, follow a colliding pair through signing and verification, and retire MD5 and SHA-1 from the verifiers that still accept them.
Design firmware updates that can recover safely
Connect trusted boot, update authorization, rollback policy and end-of-life behavior to the device’s actual failure modes.
Publish security advisories with CSAF, VEX, CVE records and OSV
What a useful security advisory contains and how to publish it in the formats tools read: a validated CSAF 2.0 VEX document, the CSAF provider files, CVE records through a CNA (CVE Record Format 5.2), and OSV records for open-source packages. Covers the status of CSAF 2.1 as of October 2026.
DeFi attack patterns: oracles, flash loans, proxies and signatures
The four smart-contract attack classes beyond reentrancy: price-oracle manipulation, flash-loan amplification, upgradeable-proxy storage collisions and uninitialized implementations, and signature replay, each with vulnerable and fixed Solidity, Foundry tests and verified incidents.
Case study: Storm-0558 and the forged Microsoft tokens (2023)
How a stolen 2016 consumer signing key and a token validation gap let Storm-0558 read enterprise Exchange Online mail in 2023, and what the review board found about rotation, logging and culture.
Practice
- Signed artifact provenance lab: Reject a release from the wrong producer · Browser lab
- JWT validation lab: Validate the purpose and audience of a token · Browser lab
- Webhook signature and replay lab: Repair a webhook handler that pays twice · Browser lab
- JWT verification lab: Verify a JWT before trusting it · Browser lab
- Insecure randomness lab: Generate unguessable API keys · Browser lab
- Secure a real HTTP API · Local project
- Build and verify a signed software release · Local project
- Verify tokens through rotation and revocation · Local project
- Prove deprovisioning reaches sessions and queued work · Local project
- Recover from failed firmware updates with A/B slots · Local project
References
List data from MITRE; the name, definition and consequences are from MITRE’s CWE 4.20 catalogue. A guide is listed as the main subject when the weakness is what the guide is about, and as covering it when a dedicated section or worked example addresses it.
CWE content: Copyright © 2006–2026, The MITRE Corporation. CWE, CWSS, CWRAF, and the CWE logo are trademarks of The MITRE Corporation. CWE™ is free to use by any organization or individual for any research, development, and/or commercial purposes, per these CWE Terms of Use. Accordingly, The MITRE Corporation hereby grants you a non-exclusive, royalty-free license to use CWE for research, development, and commercial purposes. Any copy you make for such purposes is authorized on the condition that you reproduce MITRE’s copyright designation and this license in any such copy. CWE is a trademark of The MITRE Corporation. CWE Terms of Use.