Example report · synthetic data

This is an illustration of the report, not a scan of a real app.

Security report / url

demo.example

2026-10-23 12:00:00 UTC · 42.0 s · scanner demo

Detected risk

High risk detected

Address the highest-priority findings first

0 critical1 high1 medium0 minor

Finding score: 69/100 · scoring v2 · provisional: incomplete checks. This is not a probability of compromise.

Check coverage

Partial coverage

Checks completed: 3 / 5

Unchecked areas may contain issues. An empty finding list does not mean that a check succeeded.

Inspect check details

Find a findingSeverityCategoryFix instructions for

2 of 2 findings

highAuth & access

A login token that anyone can forge (JWT "alg:none")

An unsigned token was found in the example JavaScript. Server acceptance was not tested.

Why it matters

We found a JSON Web Token (the thing that proves a user is logged in) that is marked "alg":"none" — meaning it carries NO signature at all. A signature is what stops someone hand-editing a token to say "I am the admin". If your server accepts unsigned tokens like this one, anyone can craft a token for any user and walk straight in. We did not send or test it anywhere — we only read it from your code.

Evidence

Example /assets/app.js — JWT header: { "alg": "none" }. Token: [redacted].

Confidence & verification

Confidence was not provided by this detector. Severity is not proof of exploitability.

How to fix · generic

1) Find where tokens are verified. 2) Pin the algorithm: pass an explicit allow-list (e.g. algorithms: ["HS256"]) to your JWT verify function and never trust the "alg" from the token header. 3) Confirm a token with "alg":"none" is rejected. 4) Rotate your signing secret/keys if unsigned tokens may have been accepted.

Example code · jsonwebtoken (Node)

Always pass an explicit algorithms allow-list — this is what rejects "alg:none".

import jwt from "jsonwebtoken";

// ❌ Vulnerable: no algorithms list — "alg":"none" tokens slip through
const claims = jwt.verify(token, secret);

// ✅ Fixed: pin the algorithm; an unsigned/none token is rejected
const claims = jwt.verify(token, secret, { algorithms: ["HS256"] });

Verify the change

Apply the fix, then run another scan with the same scope. Review the evidence and check coverage. This report is a snapshot; copying a fix or starting a scan does not mark the issue as fixed.

highAuth & access

A login token that anyone can forge (JWT "alg:none")

An unsigned token was found in the example JavaScript. Server acceptance was not tested.

Why it matters

Evidence

Example /assets/app.js — JWT header: { "alg": "none" }. Token: [redacted].

Confidence & verification

Confidence was not provided by this detector. Severity is not proof of exploitability.

How to fix · generic

1) Find where tokens are verified. 2) Pin the algorithm: pass an explicit allow-list (e.g. algorithms: ["HS256"]) to your JWT verify function and never trust the "alg" from the token header. 3) Confirm a token with "alg":"none" is rejected. 4) Rotate your signing secret/keys if unsigned tokens may have been accepted.

Example code · jsonwebtoken (Node)

Always pass an explicit algorithms allow-list — this is what rejects "alg:none".

import jwt from "jsonwebtoken";

// ❌ Vulnerable: no algorithms list — "alg":"none" tokens slip through
const claims = jwt.verify(token, secret);

// ✅ Fixed: pin the algorithm; an unsigned/none token is rejected
const claims = jwt.verify(token, secret, { algorithms: ["HS256"] });

Verify the change

Apply the fix, then run another scan with the same scope. Review the evidence and check coverage. This report is a snapshot; copying a fix or starting a scan does not mark the issue as fixed.

highAuth & access

A login token that anyone can forge (JWT "alg:none")

An unsigned token was found in the example JavaScript. Server acceptance was not tested.

Why it matters

Evidence

Example /assets/app.js — JWT header: { "alg": "none" }. Token: [redacted].

Confidence & verification

Confidence was not provided by this detector. Severity is not proof of exploitability.

How to fix · generic

1) Find where tokens are verified. 2) Pin the algorithm: pass an explicit allow-list (e.g. algorithms: ["HS256"]) to your JWT verify function and never trust the "alg" from the token header. 3) Confirm a token with "alg":"none" is rejected. 4) Rotate your signing secret/keys if unsigned tokens may have been accepted.

Example code · jsonwebtoken (Node)

Always pass an explicit algorithms allow-list — this is what rejects "alg:none".

import jwt from "jsonwebtoken";

// ❌ Vulnerable: no algorithms list — "alg":"none" tokens slip through
const claims = jwt.verify(token, secret);

// ✅ Fixed: pin the algorithm; an unsigned/none token is rejected
const claims = jwt.verify(token, secret, { algorithms: ["HS256"] });

Verify the change

Apply the fix, then run another scan with the same scope. Review the evidence and check coverage. This report is a snapshot; copying a fix or starting a scan does not mark the issue as fixed.

mediumWeb hardening

Your Content-Security-Policy is weak

The example response policy allows unsafe-eval.

Why it matters

You do send a Content-Security-Policy, but it contains {{weakness}}, which largely cancels out its protection — it still allows the kind of injected-script (XSS) attacks a CSP is meant to block. A CSP is only as strong as its weakest source.

Evidence

Example header: script-src 'self' 'unsafe-eval'

Confidence & verification

Confidence was not provided by this detector. Severity is not proof of exploitability.

How to fix · generic

Rewrite your Content-Security-Policy without 'unsafe-inline', 'unsafe-eval', or wildcard (*) sources in script-src/default-src. Use per-response nonces or content hashes for any inline scripts you genuinely need.

Example code · Strong CSP header

A nonce-based policy — every inline <script> must carry the matching nonce.

Content-Security-Policy:
  default-src 'self';
  script-src 'self' 'nonce-{RANDOM_PER_REQUEST}' 'strict-dynamic';
  object-src 'none';
  base-uri 'none';
  frame-ancestors 'none';

Verify the change

Apply the fix, then run another scan with the same scope. Review the evidence and check coverage. This report is a snapshot; copying a fix or starting a scan does not mark the issue as fixed.

What was checked

JWT patterns

Findings: 1

Completed

Security headers

Findings: 1

Completed

Secret patterns

No findings in this check’s scope.

Completed

TLS inspection

Example: the TLS probe exceeded its time budget.

Timeout

Gitleaks

Example: optional engine not enabled.

Skipped

Scope & scan notes

Synthetic example. No real app, keys or customer data.