Application Security Engineer interview questions

No. Client-side validation is purely a UX convenience — an attacker can disable JavaScript, edit the request in the browser or Burp, or call your API directly with curl, bypassing it entirely. Security checks (validation, authorization, sanitization) must be enforced on the server, the only place you control. The misconception is treating the browser as a trust boundary; it isn't, because the client runs on the attacker's machine. Client-side checks are great for fast feedback, never for security.

You don't — cryptographic hashes are one-way functions with no inverse. 'Cracking' a hash means guessing candidate inputs, hashing each, and comparing (dictionary, brute force, rainbow tables), which is exactly why slow salted hashes are used for passwords. There is no key that 'decrypts' a hash. If something can be decrypted it was encrypted, not hashed — and Base64 is reversible encoding, not hashing.

No. Deleting the cookie just removes the credential from your browser — the session record (or a still-valid JWT) on the server typically remains usable until it expires or is explicitly invalidated. An attacker who already captured the token can keep using it. The misconception treats the cookie as the session itself; it is only a pointer to server-side state. Real logout must invalidate the session server-side, or revoke and short-TTL the token.

No. TLS/HTTPS secures data in transit between client and server; once received, the data is decrypted and handled in plaintext by the app, then stored however the database is configured. Protecting data at rest is a separate concern — disk/column encryption, a KMS, and access control. Conflating 'we use HTTPS' with 'our stored data is encrypted' is a common and dangerous misconception.

No. HTTPS encrypts the channel so attackers can't read or tamper with traffic in transit, but the malicious input still arrives, is decrypted, and is processed by your app exactly as before. SQL injection and XSS are application-layer flaws fixed by parameterized queries and output encoding, not by transport encryption. The misconception assumes encryption sanitizes content — it doesn't; the attacker simply sends the payload over the HTTPS connection.

No. POST simply carries parameters in the request body instead of the URL; that body is plaintext and fully visible to anyone who can see the traffic unless HTTPS is used. POST is preferable for state-changing actions and keeps params out of URLs, logs, and browser history, but it provides no confidentiality on its own. The misconception confuses 'not in the URL' with 'encrypted' — only TLS encrypts either method's data in transit.

No. A salt is a unique, random value stored right alongside the hash; its job is to make identical passwords hash differently and to defeat precomputed rainbow tables — not to stay secret. It's fine if an attacker who steals the database also gets the salts. What actually protects passwords is a slow, salted hash (bcrypt, scrypt, Argon2). A separate, optional secret 'pepper' is a different concept.

Unbounded autonomy plus tool access is OWASP LLM 'excessive agency': a manipulated or mistaken model can take destructive actions. Constrain it with least-privilege tool scopes, require human confirmation for irreversible operations, and keep permissions narrow and audited. Trusting it or granting admin widens the blast radius, and hiding a UI button does nothing about the model's underlying capability to call the action.

Untrusted content the model ingests can carry instructions — indirect prompt injection. You can't fully prevent the model from being influenced, so isolate fetched content as data, constrain what tools/permissions the agent has, require confirmation for sensitive actions, and avoid giving it secrets it could be coerced into leaking. Assuming the model will simply ignore injected instructions is exactly the failure mode being exploited.

A third-party model is a supply-chain dependency: verify it comes from a trusted source with matching checksums/signatures, that its license permits your use, and that the file format won't execute arbitrary code on load (prefer safe serialization over pickle-style formats). 'It loads' and 'download speed' say nothing about trust, and assuming public models are safe ignores real poisoning and deserialization risks.

This is OWASP LLM 'improper output handling': model output influenced by user input can become command injection when fed to a shell or eval. Treat it as untrusted — map intents to a small allow-list of parameterized actions, validate strictly, and sandbox execution rather than running raw generated strings. Trusting the output, raising token limits, or only logging does nothing to stop the injection.

Sending customer PII to an external API exposes it to a third party's processing and retention and can breach privacy obligations. Minimize and redact what's sent, confirm the provider's data-use/retention terms and a data-processing agreement (or no-training guarantees), or move to a private deployment for sensitive data. Key length is irrelevant, and sending more PII increases the exposure.

If retrieval pulls any indexed document regardless of who's asking, the model will faithfully surface data the user shouldn't see — this is an authorization flaw, not hallucination. Enforce the user's document-level permissions at retrieval time so only authorized chunks enter the context. A bigger system prompt is bypassable and doesn't implement access control, temperature is unrelated, and another model has the same gap.

Training on unvetted user data lets an attacker poison the model — implanting backdoors, triggers, or skewed behavior that surfaces later. Control it with data vetting and filtering, provenance tracking, anomaly detection on the dataset, and evaluation of model behavior after training. 'More data is better' ignores integrity, and the real concern is poisoning, not speed or disk space.

Password storage needs a deliberately slow, salted, memory-hard hash — bcrypt, scrypt, or Argon2 — so cracking stolen hashes is expensive and rainbow tables don't apply. A fast hash like SHA-256 is trivially brute-forced at scale; reversible encryption means one key compromise exposes every password at once; and plaintext is indefensible no matter how locked down the database is. Choose Argon2id (or bcrypt) with a tuned work factor and a unique per-user salt.

An open redirect on an auth flow lets an attacker craft a trusted-looking login link that, after authentication, sends the user — and potentially an auth code or token — to an attacker-controlled domain, enabling account takeover and convincing phishing. Fix it by strictly allow-listing exact redirect URIs server-side and rejecting anything else. It is not cosmetic and not a performance issue, and HTTPS doesn't help because the attacker's destination can be a valid HTTPS site too.

If the browser automatically attaches the session cookie, a malicious page can trigger the transfer on the victim's behalf — cross-site request forgery (CSRF). Defend state-changing requests with anti-CSRF tokens and SameSite cookies, and check the Origin/Referer header. Cookies prove identity but not intent, a login CAPTCHA does nothing for an already-authenticated action, and HTTPS protects transport confidentiality, not request forgery.

If an attacker can upload a server-executable file (or HTML/SVG) into a servable directory, they may achieve remote code execution or stored XSS. Validate the real content type, store uploads outside the web root or on a non-executing store, randomize filenames, and serve them so they can't be executed or interpreted as markup. Slower page loads and disk usage are operational issues, not the security risk an attacker exploits here.

Server-side fetching of attacker-controlled URLs is server-side request forgery (SSRF): it lets an attacker reach internal-only services or the cloud metadata endpoint to steal credentials. Mitigate by allow-listing permitted hosts and schemes, blocking private and link-local ranges (re-checking after every redirect), and hardening metadata access with IMDSv2. Saying there's no risk ignores the access the fetch grants, and a loading spinner or response caching does nothing about where the server is allowed to connect.

This is broken access control (IDOR): the server isn't checking that the authenticated user may access the requested object. The fix is per-object authorization enforced server-side on every request. Sanitizing the number doesn't establish ownership. Encrypting or obfuscating the ID is obscurity that's still guessable, leakable, or replayable. The HTTP method is irrelevant to authorization. Always verify the caller's right to the specific object before returning it.

`alg: none` lets anyone craft a valid-looking unsigned token and impersonate any user — a full authentication bypass, not a minor finding. Fix it by allow-listing the expected algorithms server-side and always verifying the signature with the right key; never trust the token's own alg header to pick the verification method. Longer expiry or moving where the token is stored does nothing about forged, unsigned tokens. This is critical and exploitable, so document is not a fix.

Prompt injection can't be fully solved with more prompt text; assume the model can be subverted and constrain what it's allowed to DO. Give tools least privilege, gate high-impact actions behind human confirmation, and validate or sandbox tool calls before acting (OWASP LLM 'excessive agency' and 'improper output handling'). System-prompt pleading is bypassable. Higher temperature only adds randomness, and logging alone records the damage without preventing the injected action.

This is a mass-assignment (over-posting) flaw: the server blindly maps client JSON onto sensitive model fields. Fix it by binding only an explicit allow-list of permitted fields (DTOs / strong params) so privileged attributes like isAdmin can't be set by the client. Hiding the field in the frontend and adding client-side validation are both bypassed by a raw request. Renaming isAdmin is obscurity that's easily discovered. Control which fields bind, server-side.

Parameterized queries are the actual fix: they separate code from data so user input is always treated as a value, never as SQL that can change the query's structure. Manual escaping is error-prone and bypassable across encodings and dialects. A WAF is a compensating control, not a fix, and encoding tricks defeat it. A length check doesn't stop injection at all. Fix it at the query layer.

Stored XSS is fixed by encoding data for the exact context where it's rendered (HTML body, attribute, JavaScript, URL) so the browser treats it as text, with a Content-Security-Policy as a second layer. Blacklisting the word 'script' is trivially bypassed via event handlers, mixed case, and encodings. You can't make your users disable JavaScript. Asking users not to enter HTML isn't an enforceable control. Encode on output, every time you render.

Transitive code runs in your app, so a critical CVE is your risk. Assess whether the vulnerable code path is actually reachable, then remediate by bumping or overriding the version (or mitigating) and verify in production. Ignoring it because it's transitive leaves a known hole an attacker can exploit. Suppressing the audit just hides the warning. Reinstalling node_modules pulls the same vulnerable version. Track it through SCA, don't silence it.

Threat modeling is cheapest and most effective at design time, before code locks in decisions: walk the data flows, enumerate threats with a framework like STRIDE, and bake in mitigations, then revisit as the design evolves. Doing it only post-incident or at the annual pentest finds problems after they are expensive to fix and already exposed. And relying on 'careful developers' is a hope, not a repeatable, auditable control.

Secrets belong in a managed store with access control, audit, and rotation, injected at runtime — never committed to source control. Use a secrets manager (AWS Secrets Manager, HashiCorp Vault) and remove the committed values from history, then rotate them because they must be treated as compromised. Base64 is encoding, not protection — anyone can decode it. A private repo still spreads the secret to everyone with clone access plus CI systems and forks. Compiling it into the binary just hides a secret that's still trivially extractable.

Sensitive data should never reach logs: redact or mask at the source first to stop the bleeding, then remediate the historical logs and tighten access. PCI DSS forbids storing full PANs and CVVs this way, and passwords should never be logged at all. 'Internal' logs are still a prime breach target. Encrypting or ACLing the store still leaves cleartext secrets sitting in logs for anyone with read access — backups, SIEM pipelines, and admins all see them.

Direct prompt injection is when a user types adversarial instructions straight into the prompt to override the system prompt or safety rules. Indirect prompt injection hides malicious instructions inside external content the model later ingests — a web page, email, PDF, or RAG document — so the attack fires without the victim ever typing it. Indirect injection is the bigger risk because the attacker and the victim are different people, and the payload rides in on data the app implicitly trusts.

Insecure output handling is trusting what the model returns and passing it to a downstream system without validation or encoding. Because model output is attacker-influenceable, rendering it as raw HTML causes XSS, feeding it to a URL fetcher causes SSRF, and passing it to a shell or SQL query causes command or SQL injection. The fix is to treat model output exactly like untrusted user input: context-aware output encoding, allowlisting, sanitization, and parameterization before it reaches any sink.

A jailbreak targets the model's safety alignment — it tricks the model into producing content the provider tried to prohibit, like instructions for harm. Prompt injection targets the application's instruction hierarchy — it overrides the developer's system prompt or hijacks the model's behavior within an app, often via untrusted data. Jailbreaks attack the model; prompt injection attacks the surrounding system. They overlap, but the goal and the trust boundary they cross are different.

The LLM supply chain spans base models, fine-tuned variants, datasets, embeddings, plugins, libraries, and the hosting platform — each a place to introduce risk. Threats include downloading tampered or backdoored model weights, malicious fine-tunes, poisoned or license-tainted datasets, vulnerable or over-permissioned plugins, and typosquatted model repos. Defenses: source models from trusted registries, verify integrity and provenance, maintain an AI bill of materials, scan and pin dependencies, vet plugins, and apply least privilege to anything the model integrates with.

The OWASP Top 10 for LLM Applications is the consensus list of the most critical risks when building with large language models. The 2025 edition covers prompt injection, sensitive information disclosure, supply chain, data and model poisoning, improper output handling, excessive agency, system prompt leakage, vector and embedding weaknesses, misinformation, and unbounded consumption. It exists because traditional appsec lists don't capture LLM-specific failure modes, and it gives teams a shared vocabulary and a checklist to prioritize controls.

RAG security means treating every retrieved document as untrusted input. Key risks: indirect prompt injection hidden in retrieved content, poisoning of the knowledge base or embeddings, and missing per-user authorization so the model returns data the user can't access. Defenses include access control enforced at retrieval, content provenance and ingestion vetting, treating retrieved text as data not instructions, output validation, and isolating the vector store per tenant.

An LLM agent turns text into actions via tools and function calls, so a prompt injection becomes a real-world action — the excessive-agency risk. Secure it by giving each tool the least privilege and scope it needs, validating and constraining tool arguments, requiring human confirmation for sensitive or irreversible actions, sandboxing execution, rate-limiting and budgeting calls, and logging every tool invocation. Never let the model's untrusted-data-influenced output directly authorize a high-impact action.

LLM apps leak data several ways: the model memorizes and regurgitates sensitive training or fine-tuning data, the system prompt (which may hold secrets or logic) gets extracted, retrieved RAG documents expose data the user shouldn't see, and context from one user or session bleeds into another. Prevention means data minimization before training, never putting secrets in prompts, enforcing per-user authorization on retrieval, output filtering and PII redaction, and tenant isolation.

Training-data poisoning is when an attacker tampers with the data used to pre-train, fine-tune, or embed a model so the resulting model behaves maliciously — embedding a backdoor trigger, injecting bias, or degrading accuracy. It exploits the fact that models scrape and trust large, often web-sourced datasets. Defenses include curating and signing data sources, provenance and integrity checks, anomaly detection on training data, dataset versioning, and limiting who can contribute to training and RAG corpora.

Embed security at every SDLC phase rather than testing at the end: requirements include security and privacy requirements, design includes threat modeling, development follows secure coding standards with SAST, testing adds DAST and reviews, and release requires sign-off — all governed by policy, separation of duties, and change control. Fixing flaws early is dramatically cheaper than after release.

Start from a minimal, trusted base image (distroless or slim) to shrink attack surface, scan images for known CVEs in CI and in the registry, pin and verify image digests, run as a non-root user, and avoid baking in secrets. Sign images and enforce admission policies so only scanned, signed images run. Rebuild regularly so patched base layers flow through.

RBAC controls what identities can do against the Kubernetes API — Roles and ClusterRoles grant verbs on resources, bound to subjects via RoleBindings — and should follow least privilege, avoiding cluster-admin and wildcards. Network policies control pod-to-pod traffic, which is allow-all by default until you apply a default-deny and then explicitly permit required flows. Together they limit blast radius if a pod or token is compromised.

Store secrets in a dedicated managed service (Secrets Manager, Parameter Store, Vault), encrypted with a KMS key, and grant access through IAM roles so workloads fetch them at runtime with short-lived credentials. Never bake secrets into code, container images, or committed .env files. Add automatic rotation, scoped key policies, and audit logging so every retrieval is traceable.

CI/CD is high-value because it holds deploy credentials and runs untrusted code. Risks include compromised dependencies and build actions, leaked or over-broad secrets, mutable third-party actions, and over-privileged runners or OIDC trust. Reduce them with pinned and verified dependencies, short-lived OIDC federation instead of long-lived keys, least-privilege scoped to specific repos/branches, isolated ephemeral runners, and signed, provenance-tracked artifacts (SLSA).

A digital signature is the hash of a message transformed with the signer's private key. The verifier recomputes the hash, applies the signer's public key, and checks they match. Because only the signer holds the private key, a valid signature proves the message came from them (authenticity), wasn't altered (integrity), and that they can't credibly deny it (non-repudiation).

HMAC is a keyed message authentication code: it hashes the message together with a secret key using a nested construction (inner and outer hash with key-derived pads). It proves both integrity (the message wasn't altered) and authenticity (it came from someone holding the key). A plain hash proves neither, since anyone can recompute it; HMAC also resists length-extension attacks.

A JWT is three base64url parts — header, payload (claims), and signature — joined by dots. The server signs the header and payload with a secret or private key, and verifies that signature on each request to trust the claims without server-side session state. Pitfalls: accepting alg=none, RS256-to-HS256 key confusion, not validating expiry/issuer/audience, putting secrets in the readable payload, and no revocation path.

The app redirects the user to the authorization server to log in and consent. The server redirects back with a short-lived authorization code. The app's backend then exchanges that code (plus its client secret) at the token endpoint for an access token, over a server-to-server back channel. This keeps tokens out of the browser/URL. Public clients add PKCE to bind the code to the original requester.

Store passwords using a deliberately slow, salted, adaptive password-hashing function — bcrypt, scrypt, or Argon2 — never a fast general-purpose hash like SHA-256 or MD5. Fast hashes are built for speed, so attackers with GPUs can test billions of guesses per second against a leaked database. Slow hashes have a tunable work factor (and memory cost) that makes each guess expensive, keeping brute force impractical even after a breach.

A salt is a unique, random value generated per user and combined with the password before hashing. It ensures identical passwords produce different hashes and makes precomputed attacks like rainbow tables useless, since the attacker would need a separate table per salt. Salts are stored alongside the hash. A pepper is an additional secret value, the same for all users, kept separately (e.g., in app config or an HSM) so a database leak alone isn't enough.

TOTP (Time-based One-Time Password) combines a shared secret, established at enrollment, with the current time divided into fixed windows (usually 30 seconds). It runs HMAC over the time-step counter with the secret, then truncates the result to a 6-digit code. Both the app and server hold the same secret and clock, so they independently compute the same code — no network call needed. The code rotates each window.

Signing cryptographically binds an artifact to its producer so consumers can verify it wasn't tampered with or swapped. Provenance is signed metadata describing how, where, and from what source the artifact was built. Together — via tooling like Sigstore for keyless signing and the SLSA framework for provenance levels — they let a deployer verify an image came from the expected pipeline and source, defeating tampering and dependency-substitution attacks.

Scan images for known CVEs in OS packages and app libraries, plus misconfigurations and embedded secrets, both at build time and continuously in the registry — because new CVEs appear after an image is built. Use minimal or distroless base images to shrink the attack surface, pin and digest-reference base images, and run the container as non-root. Scanning is necessary but doesn't replace runtime protection.

Lockfiles pin exact dependency versions and hashes so every build resolves the same, verified bytes — making builds reproducible and blocking silent malicious updates. Pinning by digest, verifying integrity hashes, and scoping internal packages to a private registry also defend against dependency confusion, where an attacker publishes a higher-version public package matching an internal name to hijack resolution. The principle: never let the build silently pull unverified code.

IaC scanning statically analyzes Terraform, CloudFormation, Kubernetes, and similar definitions against policy to catch misconfigurations — public S3 buckets, open security groups, missing encryption — before they're ever provisioned. Because the same template provisions many resources, fixing it once prevents repeated drift, and catching it pre-apply is far cheaper than remediating live cloud resources. Tools include Checkov, tfsec, and KICS, ideally enforced as policy-as-code gates.

SAST reads source code without running it, finding flaws like injection sinks early but with many false positives. DAST attacks the running app from the outside with no code visibility, finding real exploitable issues but late and with shallow coverage. IAST instruments the running app to correlate runtime behavior with code, getting accurate results with code context, but needs an exercised application and agent support.

Use defense in depth: pre-commit hooks (e.g. gitleaks) catch secrets before they ever land, server-side CI scanning catches what slips past, and periodic full-history scans find old leaks. Critically, a secret that reached a remote repo must be treated as compromised and rotated — deleting the commit doesn't help because it lives in history, forks, and logs. Pair this with a real secrets manager so secrets aren't in code at all.

Break the build only on high-confidence, high-severity, newly introduced findings; warn (don't block) on everything else so developers keep trust in the gate. Manage false positives with tuned rules, baselining of pre-existing issues, and documented, time-boxed, reviewed suppressions rather than disabling scanners. A gate that cries wolf gets ignored or bypassed, so signal quality is the whole game.

Shifting left means moving security earlier — into design, the IDE, and the pull request — where issues are cheaper to fix than in production. You avoid blocking developers by making the secure path the easy path: fast in-context feedback, low-false-positive gates that only hard-fail on high-severity new issues, secure defaults and paved-road templates, and treating security as enablement rather than a late veto.

SCA inventories the open-source and third-party components an application pulls in — including transitive dependencies — and flags those with known CVEs or problematic licenses. It matters because most modern code is dependencies you didn't write, and a single vulnerable transitive package (like Log4j) can expose the whole app. Good SCA prioritizes by reachability and exploitability, not just raw CVE counts.

An SBOM is a machine-readable inventory of every component, library, and dependency in a piece of software, with versions and ideally hashes. It matters because when a new vulnerability drops, you can query your SBOMs to instantly answer 'are we affected and where?' instead of scrambling. The two dominant standards are SPDX and CycloneDX, and SBOMs are increasingly required by regulation and procurement.

Encoding (like Base64) is a reversible format change with no secret — not security. Encryption is reversible with a key and protects confidentiality. Hashing is a one-way function producing a fixed-length digest, used for integrity checks and password storage, and cannot be reversed back to the input.

It confirms XSS. If alert() fired at all, the browser parsed and executed your injected JavaScript in the page context — that is the vulnerability. A blank/empty popup just means the string argument you passed didn't render as expected (quote handling, encoding, or context mangling broke the message), not that the payload is being blocked. The execution sink is live; you refine the payload from here.

Compress first, then encrypt. Good encryption produces output that is statistically indistinguishable from random, so ciphertext has no patterns left to compress — compressing afterward is pointless. The important caveat: compressing secret and attacker-controlled data together before encryption can leak information through ciphertext length, which is exactly the CRIME and BREACH attacks.

No. CORS is not a defense against CSRF — it actually loosens the same-origin policy so a page can read cross-origin responses it otherwise couldn't. CSRF doesn't need to read the response; it just needs the victim's browser to send an authenticated state-changing request. The real defenses are anti-CSRF tokens, the SameSite cookie attribute, and checking Origin/Referer.

Encoding transforms data into another format for compatibility and is fully reversible by anyone with no key (e.g. Base64, URL encoding) — it provides no confidentiality. Encryption is reversible only with a key and is what provides confidentiality. Hashing is a one-way function: you cannot recover the input from the output, which is why it suits integrity checks and password storage (with a salt and slow KDF).

Because they are fast. MD5 and SHA-256 are designed for speed, which is exactly wrong for passwords: an attacker who steals the hashes can compute billions of guesses per second on a GPU. The fix is a deliberately slow, memory-hard key-derivation function — bcrypt, scrypt, or Argon2 — combined with a per-user salt and a tunable work factor.

The WSTG is a checklist-backed methodology that walks an app through testing categories: information gathering, configuration and deployment, identity and authentication, authorization, session management, input validation (injection/XSS), error handling, cryptography, business logic, and client-side. It gives systematic coverage with stable test IDs so findings are reproducible and nothing obvious gets skipped.

Start by understanding the app's threat model and where it handles untrusted input, secrets, authentication, and authorization. Use SAST to scan broadly and DAST against the running app, but treat tool output as leads, not findings — triage out false positives. Then spend human time on the high-value, context-dependent areas tools miss: authz logic, business logic, crypto usage, and trust boundaries. Trace data flow from source to sink.

A secure SDLC embeds security into every phase rather than testing at the end: requirements (security and abuse cases), design (threat modeling), implementation (secure coding standards, SAST/SCA in the IDE and CI), testing (DAST, pentest), release (gates and sign-off), and operations (monitoring, patching, feedback). Shift-left moves defects earlier where they're cheap to fix; maturity models like OWASP SAMM and BSIMM measure how well you actually do it.

Threat modeling answers four questions: what are we building, what can go wrong, what do we do about it, and did we do a good job. You diagram the system (often a data flow diagram with trust boundaries), enumerate threats with a framework like STRIDE, prioritize by risk, and assign mitigations. PASTA adds a risk- and attacker-centric flavor; attack trees decompose a single goal. Doing it at design time is far cheaper than patching production.

A forward proxy sits in front of clients and makes outbound requests on their behalf — used for egress control, filtering, caching, and anonymity. A reverse proxy sits in front of servers and receives inbound requests on their behalf — used for load balancing, TLS termination, caching, and as a security front for a WAF. The direction it faces, client-side or server-side, is the key distinction.

Identify the stack from headers and source, then brute force directories and files with gobuster or feroxbuster using a good wordlist and relevant extensions. Look for admin panels, backups, config files, and upload points, and check virtual hosts when the site responds to a hostname.

Individually, SQLi exposes or modifies data and can reach RCE; stored XSS hijacks sessions in victims' browsers. Chained, you can use SQLi to plant a stored XSS payload that fires in an admin's session, steal their session, and escalate to full application control.

Encryption is reversible — with the key you get the plaintext back; it protects confidentiality. Hashing is a one-way function producing a fixed-size digest you cannot reverse; it verifies integrity and identity. Passwords should be hashed with a slow, salted algorithm like bcrypt or Argon2, never encrypted.

Never hardcode secrets in source or commit them to git. Store them in a dedicated secrets manager or vault, inject them at runtime, scope access with least privilege, rotate regularly, and prefer short-lived dynamic credentials over long-lived static ones. Audit every access.

A secure SDLC bakes security into every phase rather than bolting it on at the end. Requirements include security and abuse cases, design adds threat modeling, development uses secure coding and SAST plus dependency scanning, testing adds DAST and pen testing, and operations adds monitoring, patching, and incident response — shifting security left.

Enforce TLS everywhere, authenticate every request (e.g. OAuth2/OIDC tokens), and authorize per-object so users can only reach their own data. Add input validation, rate limiting and quotas, schema validation, and thorough logging. The most common API flaw is broken object-level authorization, so check ownership on every resource access.

Content-Security-Policy is an HTTP response header that tells the browser which sources of scripts, styles, images, and other content are allowed to load and execute on a page. By disallowing inline script and untrusted origins — ideally via nonces or hashes — it acts as a defense-in-depth backstop that neutralizes injected XSS payloads even when one slips through.

CSRF tricks a logged-in user's browser into sending a state-changing request to a site where they are authenticated, abusing the fact that cookies are sent automatically. It is stopped with anti-CSRF tokens (a secret per-session value the attacker cannot read or guess) and the SameSite cookie attribute, which stops cookies from riding along on cross-site requests.

The OWASP Top 10 is a community-driven awareness document that ranks the most critical web application security risks, refreshed every few years from real-world data. It is not a checklist or standard but a starting point — recent entries include Broken Access Control (#1), Cryptographic Failures, Injection, and Insecure Design.

Never store passwords in plaintext or reversibly encrypted, and never with fast general-purpose hashes like MD5 or SHA-256. Use a slow, memory-hard password hashing function — Argon2id (preferred) or bcrypt — with a unique random salt per password and a tuned work factor, so an attacker who steals the database cannot feasibly crack the hashes.

Prepared statements send the query template to the database first, with placeholders, so the structure is fixed before any user data arrives. Parameters are then bound as pure data and can never be parsed as SQL — so input like ' OR 1=1 is treated as a literal string, not code. This separation is the canonical, reliable fix for injection.

The primary defense is contextual output encoding — encode untrusted data for the exact place it lands (HTML body, attribute, JavaScript, URL). Pair that with safe DOM APIs (textContent over innerHTML), framework auto-escaping, input validation, and a Content-Security-Policy as a defense-in-depth backstop that limits what scripts can run.

The Same-Origin Policy is the browser rule that script from one origin (scheme + host + port) cannot read responses from a different origin, which protects authenticated sessions. CORS is a controlled relaxation: a server returns Access-Control-Allow-Origin headers to explicitly opt in to letting specific origins read its responses, so it loosens SOP rather than bypassing it.

HttpOnly hides the cookie from JavaScript so XSS cannot steal it via document.cookie. Secure ensures the cookie is only sent over HTTPS, blocking network interception. SameSite controls whether the cookie is sent on cross-site requests, mitigating CSRF. Together they harden session cookies against the most common theft and abuse paths.

Key security headers include Strict-Transport-Security (forces HTTPS, blocks SSL stripping), Content-Security-Policy (limits script sources, mitigates XSS), X-Frame-Options or CSP frame-ancestors (blocks clickjacking), X-Content-Type-Options: nosniff (stops MIME sniffing), and Referrer-Policy (controls referrer leakage). Each addresses a specific attack class.

SQL injection lets attacker input alter a query. In-band techniques return data directly: union-based appends a UNION SELECT to pull extra columns, and error-based leaks data through database error messages. When no output is visible, attackers use blind SQLi — boolean-based infers data from true/false response differences, and time-based uses delays like SLEEP() to read data one bit at a time.

SSRF tricks a server into making HTTP (or other) requests to a destination the attacker chooses, abusing the server's network position to reach internal services behind the firewall. In the cloud it is especially severe because the instance metadata service (e.g. 169.254.169.254) can hand back IAM credentials, turning an SSRF into cloud account compromise.

HTTP is stateless — each request is independent and carries no memory of prior ones. Sessions add state on top: after login, the server issues an identifier the browser stores in a cookie and replays on every request. Server-side sessions keep the state on the server keyed by an opaque session ID; stateless tokens like JWTs put signed state in the token itself so the server can verify without storage.

All XSS injects attacker-controlled script into a victim's browser. Stored XSS persists the payload on the server (e.g. a comment) and hits everyone who views it; reflected XSS bounces the payload off the server in a single response, usually via a crafted link; DOM-based XSS never reaches the server logic — vulnerable client-side JavaScript writes untrusted input into the page.

XXE abuses an XML parser that resolves external entities defined in a document's DTD. An attacker declares an entity pointing at a local file or internal URL, and the parser fetches it — enabling file disclosure, SSRF, and denial of service. The fix is to disable DTD processing and external entity resolution in the parser configuration.