After recently completing a few interview loops for Security Engineer roles, one common requirement between different organizations is a round based on threat modeling or secure system design. There’s a good amount of confusion on discussion boards for how to prep for these interviews or how to approach them. I’ll share my approach and some tips I’ve found to be useful in clearing this style of interview.

Contrary to what your recruiter probably told you: OWASP top 10 isn’t enough prep material for these things

Always cover the basics

While it’s beneficial to touch on exotic and obscure vulnerabilities that might be relevant to the application you’re threat modeling, it’s more important to cover the basics. Interviewers are usually looking for a discussion around XSS/SQLi/CSRF.

Some interviewers treat these things like a checklist and you can cover every base but if you forgot to say we should use TLS for data-in-transit that might result in the interviewer assuming you would miss that in an actual design review.

Microservices Security Architecture

This is the part many candidates overlook, these days most companies are operating in a microservice model, the days of a 3-tier web application architecture are behind us.

You need to be able to discuss a Zero-Trust Security architecture, where each service has strong authentication/authorization between the other services it interacts with.

A network firewall should not be considered sufficient to protect a service from unauthorized access.

Deeply understand the topics you plan to discuss

It’s very common for a candidate to rapid fire list security buzzwords, but you should be ready to justify every piece of your strategy and more importantly know the trade-offs between different options.

If you say we should use OAuth for authorization that’s a good approach, but can you tell me why? Can you explain the potential risks associated with different OAuth flows? Can you explain common pitfalls in storing access tokens and validating them? If not, don’t try to BS your way around the follow-up questions.

Provide multiple solutions, discuss trade-offs and be realistic

For many security issues, there will be a “best” answer. For example we can mitigate most authentication issues if we force MFA, but in reality that’s a poor user experience and for most businesses, requiring it for every user is not a viable solution.

Instead you can offer a compromise and require MFA when a user’s IP address or device identifier changes.

You should also use defense-in-depth for your mitigation strategies. For a junior level interview it might be sufficient to mention “input validation + output sanitization” as a mitigation for XSS, but at a senior level you should be talking about how the actual libraries used to perform that filtering work as well as additional protections like CSP and HttpOnly session cookies.

Do your research and be resourceful

You should definitely be performing OSINT on both your interviewers (if you have their names) and the company itself. If you’re interviewing with a tech company there’s usually a blog they publish which will give you insight into their architecture, and more often than not some detailed posts on how they dealt with security issues in the past.

If you’re interviewing for an Appsec team that recently open-sourced a tool to manage internal CAs for mTLS between services, it’s in your best interest to spend some time learning how that works, and playing with the tool if possible.

Understand the format

Generally I’ve seen this type of interview framed in 3 different ways:

  1. Diagram: You’re presented with an architectural diagram of an application and it’s components
  2. Verbal: The prompt is a specific app/feature and you will just talk through threats/mitigations i.e. “Threat Model a chat app”
  3. Secure System Design: Similar to a Software Engineer ‘System Design’ interview you will be given a prompt for an application and expected to choose how to architect it, with the focus being on security. Threats and mitigations are usually described as you go.

Think like an attacker

Even though AppSec roles aren’t necessarily focused on offensive security, it’s very common for an interviewer to ask this follow-up question to a threat you mention:

“How would an attacker exploit this?”

“What would be the impact if this were exploited?”

If you don’t know what an XSS payload looks like, or how a session cookie can be exfiltrated through XSS you will have a hard time landing a mid-level or senior role.

It’s completely fine if you’ve never encountered these issues in a previous job, there’s plenty of free labs online to practice this, hands-on. I would recommend Portswigger’s WebSec Academy.

Ask questions first, avoid making assumptions

This is a great way to figure out the issues your interviewer expects you to focus on. You can confirm if certain categories of threats are within scope or if the protections can be assumed to already be in place, just by asking.

Clarify your approach and prioritize the threats

Every interviewer has a different style; many of these rounds are open-ended and good interviewers will let you lead the discussion to show off the areas you’re strongest in. Other interviewers will have some arbitrary check-list of issues they expect you to focus on, it can be hard to know which one of these we’re dealing with so set some expectations up front.

Some questions to ask:

“My preferred approach would be to start at the beginning of the diagram and list each threat and it’s associated mitigation for each component of the diagram, does that work for you?”

  • Some interviewers are looking for a specific methodology like STRIDE to be used, so if that’s the case it’s better to follow that format. Alternatively if the interview is geared towards adversary emulation it might not be expected/desired for you to even discuss mitigations.


Here’s an example that contains many components, this is by no means supposed to be a full threat model, interviews will be time-boxed so I’ll list the major threats that come to mind and a summarized mitigation list for each.


Single Page App

The SPA is used for browser based access to the web application, so this is a good time to think about the browser security model and the associated vulnerabilities


  • Use static HTML
    • By avoiding dynamic HTML generation you can almost eliminate all XSS issues
  • Use a templating engine
    • Make sure not to pass user-input into templates (SSTI)
  • Utilize standard libraries for HTML sanitization, avoid creating custom logic to perform sanitization
  • HttpOnly flag
    • In the event that an XSS exists, a victim’s session ID cookie can’t be stolen via document.cookie
  • CSP Response Header
  • Avoid passing input to dangerous JavaScript sinks like eval, href, innerHTML, etc


  • SameSite Cookie Attribute
    • At the minimum use it in Lax mode, which provides great protection against CSRF without breaking application functionality
  • CSRF Tokens
    • This should be a requirement, until all browsers support Same-Site cookies this is the only full protection against CSRF
  • Avoid using GET requests for state changing actions
  • Request password for sensitive actions (change pw, etc)


  • Use TLS 1.2+ for HTTP requests and only enable the use of Ciphersuites which enable Perfect Forward Secrecy.
  • HSTS
    • If possible use preload directive, set high max-age

CORS Issues

Modern applications with a SPA front-end rely on many asynchronous AJAX calls to different domains. It’s a cumbersome task to manually configure the appropriate CORS headers resulting in development teams setting overly permissive CORS policies.

  • If the request contains sensitive information, the origin should be properly specified in the Access-Control-Allow-Origin response header.

User Authentication

Credential Stuffing/Account Bruteforcing

  • Rate Limiting
    • Per IP, user, service or any combination of those factors
  • Captcha
  • MFA
  • Password length/complexity requirements

Account Enumeration

  • Use generic failure messages
    • On failed login attempts, user registration, password reset features

Weak Password Reset Feature

  • Use strong PRNG to generate unique links
  • Set short expiration on reset links
  • Map each reset link to the specific user who requested it

Session Management

Session Hijacking

  • Use short-lived session IDs
  • Use long and randomly generated session IDs
  • Set session ID as a cookie, so it can be used with HttpOnly and Secure flags, providing additional protection against XSS and MiTM attacks.

Mobile App

Data Exposure to Other Applications

  • Use the appropriate data sharing and storage APIs for each mobile OS.

Mobile developers must be aware of known and legitimate data sharing capabilities in each platform, such as the UI Pasteboard (iOS), SD Cards (Android, Windows Phone), temp directories, cache locations, log files etc

Smart Fridge (IoT)

Unauthorized Access

  • Ensure every device is provisioned with a unique set of credentials (don’t hardcode them)

Insecure Network Services

  • Restrict open ports to the necessary minimum
  • Only use secure protocols


Microservice based applications with multiple client-types and heterogenous services usually use a standardized communication method: REST. You can probably assume that is the case here and that most of the common issues will be relevant.

Broken Authentication

  • Ensure tokens are signed by a trusted issuer, with a strong algorithm.
  • Validate the sig and aud parameter of tokens


  • Use deny by default for controller methods
  • At the minimum use role-based access controls
  • Centralized permission evaluators are a great way to ensure all services are compliant with proper authorization checks. Open Policy Agent
    is another good approach provide this functionality

Mass Assignment

  • Allow-list non-sensitive fields
  • Block-list sensitive fields
  • Use Data Transfer Objects, there are per framework solutions to achieve this for most modern web application frameworks
  • Do not use client side filtering which can easily be bypassed

Security Misconfigurations

  • Disable unnecessary HTTP methods on API resources
  • Avoid displaying strack traces in responses



  • Parameterized Queries
  • Password Hashing
    • In the event a SQL injection does occur the passwords will won’t be accessible

Unauthorized Access

  • Ensure only the necessary port is exposed
  • Use TLS for the DB connection
  • Disable user login if possible

Microservice Security

Service to Service Authentication

  • mTLS
  • JWT
  • Trust the Network

Service to Service Authorization

  • mTLS
  • JWT

Passing end user user context between services

  • Avoid using HTTP headers for this, if the calling service wants to spoof the header the recipient service has no way to verify the authenticity
  • Pass it through a signed JWT, either the service signs it with a key-pair issued from a trusted CA or gets a trusted STS to sign the JWT


Weak Encryption

  • Use standard cryptographic libraries (don’t roll your own)
  • Avoid weak encryption/hashing algorithms
    • Use AES256-GCM for data-at-rest
    • Use Unique IVs for each round of encryption
    • For hashing passwords in a DB use a purpose built password hashing KDF such as bcrypt or scrypt

OS Vulnerabilities

  • Containerization
  • Golden Images

Supply Chain Attacks

  • Maintain a Software Bill of Materials (SBOM)
  • Use Software Composition Analysis tools (SCA)
  • Reduce the number of 3rd party dependencies your application uses

Secrets and Key Management

  • Don’t harcode secret values in source code
  • Fetch secrets from mounted volumes, through an orchestrator or environment variables
  • Use a KEK (Key Encryption Key) with a trusted vault service like KMS/CyberArk/Hashicorp Vault.
    • Each time your application needs to encrypt data a new data key can be created without ever exposing the master key

Denial Of Service

  • WAF
  • Rate Limiting
  • Auto scaling groups per service
  • File upload size limits

Design Recommendations

For every interview I’ve done, it was fair game to suggest additional components to the application. This will usually be done as you list threats through the discussion, but to keep this post organized I’ll list them here:

OAuth + OpenID Connect

I’d recommend OAuth as it’s a standardized and vetted framework for authorizing requests, this will reduce the likelihood of security issues related to building our own auth logic for the application.

For the specific implementation, I would use Authorization Code flow with PKCE (Proof Key for Code Exchange). This is especially important for browser based web applications.

OpenID (an extension to OAuth) will allow users to authenticate with 3rd party services, which offloads the responsibility of storing their credentials.

  • Ensure access tokens are not stored in LocalStorage and sent as an Authorization header in the SPA. A session ID cookie should be used instead and exchanged for an access token internally.
  • Alternatively if the JWT can fit; it can be stored as a cookie.

Edge Authentication

To simplify the authentication of requests, and reduce the amount of potential design flaws all requests can be authenticated at the edge (API Gateway)

The API Gateway will validate the request with it’s associated access token or session ID and forward it to the service it’s destined for.

Auth Service

To handle all authentication/authorization. In this context it can also be referred to as an STS (Secure Token Service). The following tasks will be handled by this service:

  • Generating OAuth Tokens
  • Validating Tokens
  • Exchanging session IDs for JWTs to be used across internal services


Using a centralized logging service can prevent important logs from being lost or destroyed in a potential compromise

Make sure not to log sensitive information such as credentials, PII or payment card information.

Valuable Resources: