Refund initiated within configured timeframe of cancellation
Why it matters
Without a defined refund window, refunds can theoretically be issued for orders cancelled two years ago — a refund policy violation that a simple date comparison prevents. Beyond fraud prevention, the absence of a configured timeframe means your refund policy (stated in terms and conditions) and your code are inconsistent: the policy says '30 days', the system enforces no limit. CWE-285 applies when a time-based access control exists in policy but not in code. The fix is a single numeric constant — REFUND_WINDOW_DAYS in lib/orders/config.ts — that makes the policy machine-enforceable and auditable.
Severity rationale
Low because the practical risk requires a customer to request a refund long after the window and the system to process it, which is unlikely but not impossible without the guard.
Remediation
Define the refund window as a named constant in lib/orders/config.ts and enforce it with a date comparison at the start of the refund handler at app/api/orders/[id]/refund/route.ts.
// lib/orders/config.ts
export const REFUND_WINDOW_DAYS = 30
// app/api/orders/[id]/refund/route.ts
import { REFUND_WINDOW_DAYS } from '@/lib/orders/config'
const daysSinceCancellation = Math.floor(
(Date.now() - order.cancelledAt!.getTime()) / (1000 * 60 * 60 * 24)
)
if (daysSinceCancellation > REFUND_WINDOW_DAYS) {
return Response.json(
{ error: `Refund window of ${REFUND_WINDOW_DAYS} days has passed.` },
{ status: 409 }
)
}
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 Order Management Audit. The pattern definition, severity rationale, and remediation remain openly licensed under CC-BY-4.0.
External references
- cwe · CWE-285 — Improper Authorization
- iso-25010:2011 · functional-correctness — Functional Correctness
Taxons
History
- 2026-04-18·v1.0.0·Initial import from ecommerce-order-management·automated