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
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.
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.
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.
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.
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.
Generally I’ve seen this type of interview framed in 3 different ways:
- Diagram: You’re presented with an architectural diagram of an application and it’s components
- Verbal: The prompt is a specific app/feature and you will just talk through threats/mitigations i.e. “Threat Model a chat app”
- 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.
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.
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.
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.
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
- In the event that an XSS exists, a victim’s session ID cookie can’t be stolen via
- CSP Response Header
- At the minimum use it in
Laxmode, which provides great protection against CSRF without breaking application functionality
- At the minimum use it in
- 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.
- If possible use preload directive, set high max-age
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
- Rate Limiting
- Per IP, user, service or any combination of those factors
- Password length/complexity requirements
- Use generic failure messages
- On failed login attempts, user registration, password reset features
- Use strong PRNG to generate unique links
- Set short expiration on reset links
- Map each reset link to the specific user who requested it
- 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.
- 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
- Ensure every device is provisioned with a unique set of credentials (don’t hardcode them)
- 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.
- Ensure tokens are signed by a trusted issuer, with a strong algorithm.
- Validate the
audparameter 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
- 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
- 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
- Ensure only the necessary port is exposed
- Use TLS for the DB connection
- Disable user login if possible
Service to Service Authentication
- Trust the Network
Service to Service Authorization
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
- Use standard cryptographic libraries (don’t roll your own)
- Avoid weak encryption/hashing algorithms
- 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
- Golden Images
- Maintain a Software Bill of Materials (SBOM)
- Use Software Composition Analysis tools (SCA)
- Reduce the number of 3rd party dependencies your application uses
- 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
- Rate Limiting
- Auto scaling groups per service
- File upload size limits
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:
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
Authorizationheader 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.
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.
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.