{
  "id": 1293038,
  "title": "Security questions every senior backend engineer should handle",
  "url": "https://urgent.news/2026/08/16/security-questions-every-senior-backend-engineer-should-handle",
  "topic": "tech",
  "section": "Tech",
  "published": "2026-08-16T14:57:00.000Z",
  "source": {
    "name": "Dev.to",
    "slug": "dev-to",
    "url": "https://dev.to/moputa/security-questions-every-senior-backend-engineer-should-handle-2n3g"
  },
  "original_language": "en",
  "account": "Every senior backend engineer should be prepared to address several key security questions. While a security engineer might be interviewed specifically for their security expertise, technical candidates are usually evaluated on their awareness of security implications during system design. The key themes include treating input as hostile, focusing on authorisation bugs, secure password storage, sessions and tokens, injection prevention, separation of concerns in handling XSS and CSRF, secure secret management, rate limiting, and demonstration of instinctual security thinking.\n\nSenior engineers should demonstrate not just technical competence, but an instinctual approach to security. They should naturally consider potential abuse cases, even when not explicitly asked about them. For example, when describing a system, an experienced engineer will instinctively ask who could abuse it and why. This instinct is crucial for identifying and mitigating security risks early in the design process.\n\nAuthentication and authorisation are related but distinct concepts. While authentication verifies who a user is, authorisation determines what actions a user can perform. A common mistake is trusting client-provided identifiers, as these can be easily manipulated by malicious users. A senior engineer should be able to articulate this risk clearly in conversation.\n\nPassword security is a near-certain interview topic. The ideal solution involves using a slow, memory-hard hashing algorithm like bcrypt or argon2 with a tunable work factor. This approach protects against offline cracking attempts following a data breach. Salts should be unique per user and stored alongside the hashed password. Constant-time comparison functions should be used to prevent timing side-channel attacks that could reveal information about existing accounts.\n\nStateless tokens and server-side sessions are both valid approaches, each with trade-offs. Stateless tokens improve scalability by avoiding per-request lookups, but they require careful revocation mechanisms since a stolen token remains valid until expiration. A robust solution involves using short-lived access tokens in conjunction with refresh tokens, and implementing a deny list for high-risk endpoints. Server-side sessions, while convenient, can be vulnerable to session fixation attacks and require more complex revocation strategies.\n\nInjection vulnerabilities are a recurring concern, particularly for backend engineers. The preferred approach is to use parameterised queries that separate user input from the SQL statement itself. This technique prevents attackers from injecting malicious SQL code by ensuring that user data is never parsed as part of the query structure. Escaping input is insufficient because it is prone to errors, whereas parameterisation offers a robust, structural solution to injection attacks.\n\nCross-site scripting (XSS) and cross-site request forgery (CSRF) are often confused but have distinct mitigation strategies. XSS involves executing untrusted content within a web page, and can be prevented through proper output encoding and the implementation of a Content Security Policy (CSP). CSRF, on the other hand, occurs when a malicious site tricks a user's browser into making an authenticated request to your site. Mitigations for CSRF include using anti-CSRF tokens that cannot be read by the attacker and ensuring that all requests originate from the same site. Understanding the difference between these two types of attacks is essential for comprehensive security defense.\n\nSecure secret management is a practical topic that interviewers frequently explore. The best practice is to inject secrets at runtime from a secure secret manager or the platform's environment variables. Credentials should never be committed to version control, and in the event of a secret leak, the recommended response is to rotate the secret immediately and assess the extent of exposure. Any committed codebase compromised by a leaked secret should be treated as permanently vulnerable.\n\nRate limiting is increasingly important, especially for systems featuring login forms or resource-intensive endpoints. The ideal approach is to apply rate limiting on a per-user basis to prevent credential stuffing attacks, while also considering per-account limitations where applicable. Both strategies should be implemented at different thresholds to balance security with user experience. When scaling applications with multiple processes, sharing rate limiting state across instances becomes crucial, often requiring coordination mechanisms like distributed locks or centralized rate limiting services.\n\nThroughout the interview process, senior backend engineers should demonstrate an instinct for security. They should be able to identify potential abuse paths and propose mitigations without being prompted. This proactive approach showcases their ability to think critically about security implications, which is a key differentiator in technical hiring discussions. The ability to discuss these topics with clarity and confidence is highly valuable in the competitive job market for backend engineers.",
  "summary": "You are not being interviewed as a security engineer. You are being checked for one habit: whether, while describing a system, you notice who could abuse it. Security questions rarely arrive labelled. They show up as follow-ups inside an ordinary technical conversation, and the ones that matter come back to a single instinct: treating input as hostile and asking who this trusts and why.…",
  "key_points": [
    "Senior backend engineers must treat input as hostile",
    "Focus on authorisation bugs and secure password storage",
    "Demonstrate instinctual security thinking in system design"
  ],
  "editors_take": null,
  "illustration": null,
  "coverage": {
    "outlets": 1,
    "also_reported_by": []
  },
  "ai_generated": true,
  "disclaimer": "Summaries, key points and the editor’s take are written by software from other outlets’ reporting and may contain errors — always check the linked original."
}