Max amount limits enforced at submission
Why it matters
Without a server-side maximum, any user can craft a request with an arbitrarily large amount value and bypass whatever HTML max attribute the form presents. This opens the door to accidental or malicious over-drafts, integer overflow in downstream calculations, and Stripe or payment processor rejections that can cascade into failed order states. OWASP A03 and PCI DSS Req-6.2.4 require server-side input validation for all payment parameters — client constraints are cosmetic until the server enforces them independently.
Severity rationale
Medium because unbounded server-side amounts enable over-limit transactions that the payment processor or banking rail will reject, corrupting order state.
Remediation
Define a named constant for the limit and enforce it in the API route handler before any payment processor call.
// src/app/api/transfers/route.ts
const MAX_AMOUNT_CENTS = 99999; // $999.99 — adjust per business rules
const schema = z.object({
amountCents: z.number().int().min(1).max(MAX_AMOUNT_CENTS),
});
const { amountCents } = schema.parse(await req.json());
Also set max={MAX_AMOUNT_CENTS / 100} on the HTML <input type="number"> in src/components/TransferForm.tsx to keep client and server limits aligned.
DetectionPro
The detection method for this pattern is part of AuditBuffet Pro.
The full method (what to look for, pass and fail conditions, and how results get reported) ships inside the Financial Form Validation Audit. The pattern definition, severity rationale, and remediation remain openly licensed under CC-BY-4.0.
External references
- cwe · CWE-20 — Improper Input Validation
- owasp:2021 · A03
- pci-dss:4.0 · Req 6.2.4 — Prevent common software attacks including injection and improper input validation
Taxons
History
- 2026-04-18·v1.0.0·Initial import from finserv-form-validation·automated