Security engineer at Figma

As asked

Your product is adding a feature where users can upload arbitrary files to share with other users. Threat model it.

Sample answer outline

Use STRIDE or a similar framework. Spoofing: who can upload, is auth required, is the user-id on the upload trusted. Tampering: file type lying about MIME (sniff the content, do not trust the header), filename traversal, content-disposition tricks. Repudiation: audit log of uploads. Information disclosure: are files private by default, signed URLs with expiry. Denial of service: max file size, rate limits, virus scanning. Elevation of privilege: stored XSS via uploaded HTML, malware delivery, hosting attacker-controlled JS. Concrete mitigations: serve user content from a separate origin, force download for unknown types, scan async, signed URLs.

Expect these follow-ups

• How do you serve user-uploaded images without enabling stored XSS?
• What is your virus scanning policy and what do you do on a positive hit?
• How would you handle the same feature for a regulated industry (healthcare, finance)?

As asked

Walk me through the current OWASP Top 10. For each category, give a concrete example of a vulnerability you have seen or remediated.

Sample answer outline

The current Top 10 covers broken access control, cryptographic failures, injection, insecure design, security misconfiguration, vulnerable and outdated components, identification and authentication failures, software and data integrity failures, security logging and monitoring failures, and SSRF. The strong answer pairs each with a war story: a missing authorisation check on an admin endpoint, an unsalted password hash, a SQL injection through a dynamic ORDER BY, an SSRF that hit the cloud metadata service. The point is to show you have seen these in the wild, not to recite definitions.

Expect these follow-ups

• Which Top 10 category is most common in your experience?
• How does the Top 10 differ from the API Security Top 10?
• What is missing from the Top 10 that you would add?

As asked

An engineer commits an AWS access key to a public GitHub repo. Walk me through what you do in the next hour.

Sample answer outline

Treat the key as compromised. Rotate immediately, do not wait. Revoke the old key, generate a new one, push it via the secret manager so dependent services pick it up. Check CloudTrail for any usage of the key in the window between commit and rotation, especially from unfamiliar IPs. Remove the key from history (git filter-repo or BFG) but understand that GitHub may have already cached it and bots scrape new commits within seconds, so rotation is what matters, not rewriting history. Talk to the engineer without blame, and add pre-commit hooks (gitleaks, trufflehog) so it does not happen again.

Expect these follow-ups

• Why is rewriting history less important than rotating?
• How would you scan all current repos for past leaks?
• What is your policy for repeat offenders?

As asked

You are building auth for a new SaaS. Walk me through the choice between server-side sessions and JWTs, and explain when each is right.

Sample answer outline

Server-side sessions: a session ID cookie, state in a server store (Redis, database). Revocation is trivial (delete the row), payload stays small. Default choice for a monolithic app where the auth server and the application share a backend. JWTs: self-contained, stateless verification, scale well across services that cannot share a session store. The trap: revocation. A signed JWT remains valid until it expires unless you keep a revocation list (which defeats the statelessness). Use short access tokens with refresh tokens to bound the blast radius. Pick sessions unless you have a multi-service architecture or a specific reason to be stateless.

Expect these follow-ups

• How do you implement logout for a JWT-based system?
• When does the refresh token rotation pattern break?
• What changes if you add a mobile client to the mix?

As asked

Explain CSRF, CORS, and CSP. What does each one protect against, and where do they overlap?

Sample answer outline

CSRF: attacker tricks a logged-in user's browser into sending an authenticated request to your site. Mitigation: SameSite cookies (Lax by default in modern browsers makes most CSRF dead), CSRF tokens for state-changing requests, or rely on the fetch+JSON path which requires CORS. CORS: governs whether a script on origin A can read responses from origin B. CORS does NOT prevent the request being sent, only restricts the response from being read. CSP: declares which sources of content are allowed; mitigates XSS by blocking inline scripts and unknown script sources. Overlap: SameSite + CSRF tokens overlap on CSRF; CORS and CSP overlap on resource loading.

Reference implementation (http)

// Session cookie defaults
Set-Cookie: session=abc123; HttpOnly; Secure; SameSite=Lax; Path=/

// CSP for a typical React SPA (no inline scripts, hashed styles)
Content-Security-Policy:
  default-src 'self';
  script-src 'self' 'sha256-...';
  style-src 'self' 'sha256-...';
  img-src 'self' data: https://cdn.example.com;
  connect-src 'self' https://api.example.com;
  frame-ancestors 'none';
  base-uri 'self';
  form-action 'self';
  report-uri /csp-report

// CORS for a same-account API (only the SPA origin is allowed)
Access-Control-Allow-Origin: https://app.example.com
Access-Control-Allow-Credentials: true
Access-Control-Allow-Methods: GET, POST, PATCH, DELETE
Access-Control-Allow-Headers: Content-Type, Authorization

Expect these follow-ups

• Why does SameSite=Lax not fully kill CSRF?
• How would you write a CSP for a React SPA that uses inline styles?
• When does CORS preflight not happen?

As asked

You have 30 services running in one AWS account. Design an IAM strategy that gives each service least privilege and keeps the policies maintainable.

Sample answer outline

One IAM role per service, assumed via the workload identity (IRSA for EKS, instance profile for EC2, task role for ECS). Policies generated from infrastructure code, not hand-edited. Use IAM Access Analyzer to flag overly permissive policies and unused permissions. Avoid wildcard resource ARNs. Separate the prod and non-prod accounts to remove the worst blast-radius failure modes. Service control policies at the org level for guardrails like 'no public S3'. Rotate credentials never used (CIS benchmarks). Treat IAM as code with review.

Reference implementation (json)

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "ReadOwnConfigOnly",
      "Effect": "Allow",
      "Action": ["s3:GetObject"],
      "Resource": "arn:aws:s3:::prod-config/api/*"
    },
    {
      "Sid": "PublishToOwnTopic",
      "Effect": "Allow",
      "Action": ["sns:Publish"],
      "Resource": "arn:aws:sns:eu-west-2:123456789012:api-events"
    },
    {
      "Sid": "DenyAllOtherS3",
      "Effect": "Deny",
      "NotAction": ["s3:GetObject"],
      "Resource": "*"
    }
  ]
}

Expect these follow-ups

• How do you handle a service that needs cross-account access?
• What is your strategy for human access (engineers) to production?
• How would you scope a policy down from a wildcard that someone shipped 3 years ago?