Q: If I store my JWT in Local Storage, how do I prevent XSS from stealing it?
The Problem: Cross-Site Scripting (XSS) allows an attacker to run JavaScript in your user's browser. Since Local Storage is accessible via JS, a simple localStorage.getItem() can steal the token.
The Mitigation
Content Security Policy (CSP): Restrict which scripts can run and where they can send data.
Input Sanitization: Never trust user input; encode it to prevent script injection in browsers.
The "Gold Standard": Don't store sensitive tokens in Local Storage. Keep the Access Token (JWT) in memory (JS variable) and the Refresh Token in an HttpOnly cookie.
Q: If I use Cookies to store my Session ID, how do I prevent CSRF?
The Problem: Cross-Site Request Forgery (CSRF) tricks a logged-in user's browser into sending an unwanted request (like "transfer money") because the browser automatically attaches cookies to every request to that domain.
Anti-CSRF Tokens: Include a unique, hidden token in every state-changing request (POST/PUT) that the server validates.
SameSite Cookie Attribute: Set your cookie to SameSite=Strict or Lax so the browser won't send it during cross-site requests.
At the Edge (WAF/CDN): To block massive DDoS attacks.
At the API Gateway: To manage per-user/per-key quotas.
At the Service Level: To protect specific "expensive" database queries or third-party API calls.
Q: When would you choose ABAC over RBAC in a real-world project?
The Answer: Choose ABAC when access depends on context—like time of day, location, or specific resource ownership—rather than just a job title.
Example: Think of RBAC as a VIP list at a club (Are you on the list? Come in). Think of ABAC as a bouncer checking your ID, your sobriety, and if you’re wearing the right shoes (context matters).
Example: A healthcare app where a "Doctor" (Role) can only view a "Patient Record" (Resource) if they are the "Assigned Physician" (Attribute).
Q: What is the biggest practical difference between the Token Bucket and Leaky Bucket algorithms?
The Answer: Bursts. Token Bucket allows for a sudden burst of requests as long as there are tokens in the bucket. Leaky Bucket enforces a strict, uniform output rate regardless of the incoming pressure.
Why it matters: Use Token Bucket for APIs where users might occasionally need to load a lot of data at once; use Leaky Bucket for background processing tasks where you want to ensure your database never sees a spike.
Q: Why is Throttling considered "kinder" than simple Rate Limiting?
The Answer: Rate Limiting is a "brick wall" (429 error); Throttling is "molasses." It degrades the user experience gracefully by slowing down the response time rather than breaking the integration entirely.
Why it matters: This prevents a client’s automated retry logic from slamming your server the microsecond the rate-limit window resets (preventing the "thundering herd" problem).
Q: Does a WAF (Web Application Firewall) make my application-level validation redundant?
The Answer: No. This is called Defense in Depth. A WAF catches broad, known patterns (like common SQL injection strings) at the edge.
The Peer Perspective: Your application still needs to validate business logic that a WAF can’t see—like ensuring a user isn't trying to withdraw $1,000 from an account with a $50 balance.
Q: Why is Payload Size Limiting considered a "security" feature and not just a performance one?
The Answer: It prevents Memory Exhaustion DoS attacks. An attacker could send a massive, multi-gigabyte JSON "bomb" that forces your server to use all its RAM during parsing, crashing the service for everyone. NOTE: Mention that this should be configured at the Nginx/Load Balancer level so the "fat" request never even reaches your app code.
Q: Is IP Whitelisting a valid security strategy for a modern, public-facing Web App?
The Answer: For the public side? No, because users have dynamic IPs. But for internal communication (e.g., your Admin Panel only accepting traffic from your office VPN), it is an incredibly effective "lock" that stops random internet scans.
Q: How do you handle "Secrets Management" in a production environment?
The Problem: Hardcoding API keys or DB passwords in your source code is a major security risk.
The Solution: Use Environment Variables or dedicated Secret Managers (like AWS Secrets Manager).
The Peer Insight: Secrets should be encrypted and injected into the application at runtime, never checked into Git.