Applied capstone

FinPay's current architecture: Node.js API deployed on AWS EC2 behind an Application Load Balancer; PostgreSQL on Amazon RDS containing customer PII, payment card tokens, and transaction records; API keys issued per merchant, passed as a query string parameter; React single-page application served from S3 via CloudFront; manual deployments via SSH directly to EC2 with no CI/CD pipeline; application logs written to the EC2 instance's local disk, not forwarded to any central store.

The six researcher findings are: (1) API key visible in browser network tab and server logs via URL query parameter; (2) merchant_id in a transaction query can be changed to retrieve another merchant's history; (3) full card tokens returned in all transaction responses even when not needed; (4) SQL injection via search filter returning a database error with a partial SQL query; (5) refund endpoint accepting any refund_amount with no server-side maximum, tested with 10,000x the original transaction amount; (6) API accepts plain HTTP connections on port 80.

Applying STRIDE and the OWASP Top 10:2025 and the API Security Top 10 (2023) to each finding:

• Finding 1 (API key in URL): STRIDE: Information Disclosure (the credential is exposed in logs and history). OWASP: A07:2025 Authentication Failures. Mitigation: move the key to the Authorization request header; rotate the exposed keys immediately.
• Finding 2 (merchant_id enumeration): STRIDE: Elevation of Privilege (accessing resources beyond authorisation scope). OWASP: A01:2025 Broken Access Control and API1:2023 BOLA. Mitigation: server-side check that the authenticated merchant's ID matches the requested merchant_id before returning data.
• Finding 3 (card tokens in all responses): STRIDE: Information Disclosure. OWASP: API3:2023 Broken Object Property Level Authorisation. Mitigation: define explicit response schemas per endpoint; return card tokens only when the caller explicitly needs them and has the required scope.
• Finding 4 (SQL injection): STRIDE: Tampering (data integrity compromised) and Information Disclosure. OWASP: A05:2025 Injection. Mitigation: parameterised queries or prepared statements for all database interactions.
• Finding 5 (unlimited refund amount): STRIDE: Tampering (financial integrity). OWASP: API4:2023 Unrestricted Resource Consumption (business logic abuse variant). Mitigation: server-side maximum validation that the refund amount does not exceed the original transaction amount.
• Finding 6 (plain HTTP accepted): STRIDE: Information Disclosure (card tokens and API keys transmitted in cleartext). OWASP: A04:2025 Cryptographic Failures. PCI DSS: Requirement 4.2.1 (TLS required for cardholder data in transit). Mitigation: redirect all HTTP to HTTPS at the load balancer; enforce TLS 1.2 minimum.

API authentication weaknesses (Finding 1): (a) Query string transmission exposes the key in server logs, browser history, and referrer headers. Fix: transmit in the Authorization header. (b) One key grants all operations with no scope restriction. Fix: scope keys per operation type (read, write, refund), using OAuth 2.0 Client Credentials flow with named scopes per RFC 6749 Section 4.4. (c) For a financial API processing four million pounds daily, a static API key is a weak authentication method. Fix: migrate server-to-server integrations to OAuth 2.0 Client Credentials with short-lived access tokens, or to mTLS for the highest-assurance integrations.

Merchant portal (React SPA): The portal should use Authorization Code with PKCE (RFC 7636) for user-delegated access. The Implicit flow is deprecated in RFC 9700 because access tokens appear in URL fragments accessible to browser history and referrer headers.

Which logins need phishing-resistant credentials: not every FinPay login carries the same risk, so the second-factor tier should follow the blast radius of the account. Interactive human logins split into three groups. The engineers who deploy code and hold direct database access, and any internal operator who can authorise a refund, sit at the top: a stolen session there moves money or rewrites production, so these accounts need phishing-resistant credentials, meaning FIDO2 security keys or passkeys that are bound to the real origin and cannot be relayed through an adversary-in-the-middle proxy. Ordinary one-time codes and push prompts do not clear this bar, because a convincing proxy page harvests the code and replays it in real time. Merchant portal accounts that can issue refunds belong in the same tier for the same reason. Read-only merchant logins are lower risk and can start on an authenticator app, though passkeys are the better default everywhere. The machine-to-machine API path is not an MFA question at all: it has no human to prompt, so its answer is the scoped OAuth client credentials or mTLS described above, not a second factor.

Minimum-viable DevSecOps pipeline: At pull request: Semgrep with an injection ruleset blocks SQL concatenation patterns before merge. At dependency update: Snyk or Dependabot alerts on critical CVEs in package.json. At build: SBOM generation (cdxgen or Syft) produces a CycloneDX SBOM stored alongside the artefact. Before deployment to staging: OWASP ZAP active scan against the staging environment, failing on any HIGH finding. At release: SAST quality gate enforcement.

Current logging (console.log to local disk) does not capture: (1) authorisation failures per object (each instance of Finding 2 exploitation leaves no trace); (2) SQL error events with query context (Finding 4 generates database errors not forwarded to any central store); (3) refund amount anomalies (Finding 5 leaves no structured record).

Minimum log events for the FinPay scenario: (1) authentication.success and authentication.failure with source_ip, merchant_id, and timestamp; (2) api.access events including authenticated_merchant_id, resource_owner_id (the merchant_id in the request), endpoint, and response_status; (3) data.export events for card token returns including requesting_merchant_id and record_count; (4) database.error events with a sanitised error code (not the raw SQL error).

Detection rule for Finding 2 (BOLA enumeration): Sigma condition that counts distinct resource_owner_id values grouped by authenticated_merchant_id over a five-minute timeframe; alert if the count exceeds ten. This would have detected the T-Mobile-style enumeration within minutes rather than weeks.

PCI DSS compliance gaps: Finding 4 (SQL injection in a system containing cardholder data) directly violates Requirement 6.2.4 (protection against injection attacks). Finding 6 (plain HTTP) violates Requirement 4.2.1 (TLS for cardholder data in transit). Evidence required at audit: proof of parameterised queries in the codebase, SAST results showing no injection findings, and load balancer configuration showing HTTP redirect to HTTPS.