Skip to content
Architect's Handbook Wiki

Most Common Web Application Security Risks

Checklist · Chapter 11

Source

Section titled “Source”

Based on the OWASP (Open Web Application Security Project) annually-published top web application security risks. Architects on web apps should track the current list.

The Risks & Mitigations

Section titled “The Risks & Mitigations”

Injection

Section titled “Injection”
  • Untrusted data sent to an interpreter executes unintended commands (e.g. SQL injection / SQLi to read, alter, or delete data). Any user, internal or external, is a possible threat agent.
  • Mitigate: validate untrusted data, use parameterized SQL, apply least privilege, and layer a web application firewall (WAF) (which alone is not sufficient — it can’t catch every attack).

Broken authentication

Section titled “Broken authentication”
  • Flaws in authentication or session management.
  • Mitigate: salted password hashing, MFA, no default credentials, password-length/complexity/rotation policies, logout + short session timeouts, session IDs not in the URL and rotated after login, credentials only over secure connections. See IAM.

Sensitive data exposure

Section titled “Sensitive data exposure”
  • Failure to protect sensitive data (SSNs, credit cards, credentials).
  • Mitigate: identify sensitive data first; store only if necessary and discard early; encrypt at rest (including backups) and in transit with strong, current algorithms and proper key management; set browser directives/headers; disable caching of sensitive responses.

XML external entity (XXE) attack

Section titled “XML external entity (XXE) attack”
  • Against apps parsing XML: an external-entity reference processed by a misconfigured parser enables DoS, data disclosure, and SSRF. The billion laughs / XML-bomb attack expands nested entities to exhaust memory.
  • Mitigate: prefer a different format (e.g. JSON); otherwise disable DTDs, or disable external entities/entity expansion; keep XML libraries patched.

Broken access control

Section titled “Broken access control”
  • Missing/broken access checks let attackers act with elevated privileges.
  • Mitigate: enforce rights on the server side, not just the UI; use default deny; invalidate access tokens at logout; log failures and alert on repeated ones; test access control.

Security misconfiguration

Section titled “Security misconfiguration”
  • Insecure defaults and misconfigured components; more likely in complex apps.
  • Mitigate: configure securely before deployment; disable/remove/omit anything unnecessary (accounts, privileges, ports, services); change/disable default account passwords; don’t leak details in error messages/stack traces; keep OS, servers, DBMS, and frameworks patched.

Cross-site scripting (XSS)

Section titled “Cross-site scripting (XSS)”
  • Attackers execute scripts in the browser to hijack sessions, deface, or redirect. Three types: Reflected (untrusted data echoed without validation/escaping), Stored (persisted then rendered later), DOM (injected dynamically by client-side JS).
  • Mitigate: validate all user-supplied input and context-sensitively escape output before rendering.

Insecure deserialization

Section titled “Insecure deserialization”
  • Deserializing attacker-modified objects can enable remote code execution or tampered access-control data.
  • Mitigate: don’t accept serialized objects from untrusted sources; otherwise use integrity checks (e.g. digital signatures), isolate/low-privilege the deserialization code, and log deserialization exceptions.

Using components with known vulnerabilities

Section titled “Using components with known vulnerabilities”
  • Vulnerable third-party libraries/frameworks compromise the whole app.
  • Mitigate: track known vulnerabilities, patch/upgrade promptly, remove unused dependencies, obtain components from official sources over secure links, and replace or self-patch unmaintained libraries.

Insufficient logging and monitoring

Section titled “Insufficient logging and monitoring”
  • Enables many other attacks by letting them go unnoticed.
  • Mitigate: answer who/what/when (associate accounts with events, reconstruct timelines); centralize log management; automatic alerting; and secure the logs themselves against unauthorized access.

Unvalidated redirects and forwards

Section titled “Unvalidated redirects and forwards”
  • Attackers redirect users to malicious sites or forward to unauthorized pages.
  • Mitigate: avoid redirects/forwards where possible; if used, validate that target URLs point only to allowed destinations, review all such code, spider the site for redirects (HTTP 300–307, typically 302), and consider an interstitial “you are leaving this site” confirmation page.
Section titled “Related”

Citations

Section titled “Citations”
  • Software Architect’s Handbook (Packt, 2018), Ch.11 “Most common web application security risks”, pp. 892-904.