This is what you'll receive.

The /api/invoices/:id endpoint does not validate that the authenticated user has permission to access the requested resource. Any logged-in user can access another customer's invoices simply by changing the ID in the URL.

An authenticated attacker could download every historical invoice in the system, including personal data (name, address, tax ID), payment information, and purchase history. This represents a serious risk of personal data exposure under GDPR and could result in regulatory penalties in addition to reputational damage.

1. Log in as user A (legitimate customer)
2. Access an own invoice: GET /api/invoices/12345
3. Modify the ID in the URL: GET /api/invoices/12346
4. The response returns customer B's invoice with no authorization error

Implement an ownership check on the endpoint: validate that the authenticated user's user_id matches the user_id associated with the requested invoice before returning the data. Apply the same pattern to every endpoint that receives resource IDs in the URL.

The "message" field on the support form does not properly escape HTML submitted by the user. An attacker can inject JavaScript that runs when a support agent opens the ticket in the admin panel.

An attacker can hijack a support agent's session, stealing authentication cookies and gaining access to the admin panel. In the worst case, this could escalate to full control of the system and all customer data.

1. Create a support ticket with the message: '<script>alert(document.cookie)</script>'
2. The support agent opens the ticket in the admin panel
3. The JavaScript runs in the agent's context, exposing their session cookies

Escape all user output in the admin panel HTML. Use a sanitization library like DOMPurify or apply standard HTML encoding when rendering user text. Set a strict Content-Security-Policy as additional defense.

The JWT tokens generated by the /api/auth/login endpoint do not include the "exp" (expiration) claim. Tokens are valid indefinitely once issued, with no way to invalidate them individually.

If a token is compromised (via phishing, malware on the user's device, etc.), the attacker maintains access to the system permanently. There is no way to invalidate the token without rotating the JWT signing key, which would log out every user simultaneously.

1. Log in via POST /api/auth/login
2. Capture the JWT token from the response
3. Decode the token (jwt.io)
4. Confirm the "exp" field is missing
5. Use the token 30 days later: still valid

Add an "exp" claim with a reasonable lifetime (15-60 minutes for access tokens). Implement a refresh token system for long-lived sessions. Establish a periodic rotation of the JWT signing key.

The web server does not return important security headers in HTTP responses: Content-Security-Policy, Strict-Transport-Security, X-Frame-Options, and Referrer-Policy. These headers are the first line of defense against several types of client-side attacks.

Increases the risk of clickjacking attacks, XSS, downgrade to HTTP, and information leakage via the referrer. They are not direct attacks but reduce defense-in-depth and leave the user exposed to attack vectors that could easily be mitigated.

1. Access https://example.com with curl
2. Inspect the response headers: curl -I https://example.com
3. Verify the absence of the listed headers

Configure the web server (nginx/apache) or the proxy/CDN (Cloudflare, Vercel) to send the recommended security headers. Validate the configuration using securityheaders.com.