Security: Threat Modeling

Interviewer

Walk me through a threat modeling exercise for an e-commerce payment flow.

Candidate

I'll use STRIDE per component: System: User -> Browser -> Web Server -> Payment Service -> Payment Processor. Spoofing: Can an attacker impersonate the payment processor? Use mutual TLS between services. Verify webhook signatures with HMAC. Tampering: Can someone modify the payment amount? Sign the payment request payload with a server-side secret. Never trust the client to provide the amount - look it up from the server-side order. Repudiation: Can a user claim they didn't make a purchase? Log all payment events with timestamps and request IDs. Store audit logs in append-only storage. Information Disclosure: Credit card data should never reach our servers. Use Stripe's tokenization or iframe-based PCI-DSS compliance. For the web server, never log raw card numbers. DoS: Payment endpoint is expensive - rate-limit per user. Use a queue to decouple web requests from payment processing. Elevation of Privilege: Can a normal user refund an order? Server-side authorization checks on every payment action endpoint.

Interviewer

How would you handle a payment webhook replay attack?

Candidate

Webhooks should be idempotent. Store a unique idempotency key with each webhook event (the payment processor provides one). Before processing, check if we've already handled that key. If yes, return the previous result. Also, validate the webhook signature on every request and only accept webhooks from known IP ranges. Set a processing window - reject webhooks with timestamps older than 5 minutes.