Skip to content

application security

AI security interview questions tagged application security, across every topic.

27 questions · 6 unlocked for you

Concepts behind "application security"

Explanations of the mechanisms these questions rely on.

Foundational
Application Security
Injection VulnerabilitiesInjection happens when data from an untrusted source is combined with code for an interpreter, such as a SQL engine, a shell or a template engine, and the interpreter treats part of the data as instructions. The structural fix is to keep code and data in separate channels: parameterised queries, argument arrays instead of shell strings, sandboxed templates. Prompt injection is the same failure in an interpreter that offers no separate channel, which is why its defences look different.
Foundational
Application Security
Cross-Site Scripting and Output EncodingCross-site scripting (XSS) is injection into a browser: attacker-controlled content ends up in a page as executable script, running with the site's origin and the victim's session. It comes in stored, reflected and DOM-based forms. The fixes are contextual output encoding (frameworks do this by default), sanitisation when HTML must be rendered, and a strict Content Security Policy as a second layer. Chat interfaces that render model output as HTML or Markdown are a new and common source.
Foundational
Application Security
Server-Side Request ForgeryServer-side request forgery (SSRF) happens when an application fetches a URL that an attacker can influence, letting the attacker use the server's network position to reach internal services, cloud metadata endpoints and admin interfaces. String checks on URLs are easy to bypass. Robust defences validate the resolved IP address, connect to that exact address, re-check redirects, prefer allowlists, and route outbound fetches through an egress proxy. LLM tools that fetch web pages are SSRF primitives by design.
Foundational
Application Security
Application Security Posture Management: From Findings to OwnersASPM connects repositories, builds, deployed services and owners so scanner findings can become verified repairs. Learn correlation keys, coverage gaps, exception expiry and how OX Security, Cycode and Apiiro approach the problem.
Core
Application SecuritySign in
Content Security Policy in DepthA Content Security Policy is a response header the browser enforces for one document: it decides which scripts, styles, frames and connections the page may use, blocks the rest and can report violations. Host allowlists failed in practice because allowed domains host code an attacker can reuse. A strict policy trusts scripts by per-response nonce or by hash, propagates trust with strict-dynamic, and adds object-src and base-uri. Trusted Types closes DOM sinks. CSP limits XSS impact; it does not fix XSS or stop data leaving.
Advanced
Application Security🔒 Premium
How Browsers Separate Origins: SOP, CORS and CSRFThe same-origin policy lets a page send requests almost anywhere but stops its script reading responses from other origins. CORS is the server's way to relax that read restriction for chosen origins; it never stops a request being sent. CSRF is the attack that exploits sending: a cross-site page makes the victim's browser submit a request with the victim's cookies. The defences are separate: exact CORS allowlists for reads, and for writes a CSRF token, Fetch Metadata checks, strict content types and SameSite cookies as defence in depth.