Web App Hardening Checklist: Stop the Most Common Attacks

The rapid growth of web-based services — particularly API-driven architectures — reflects an increasing reliance on distributed systems that expose sensitive data to security risks, making systematic hardening more important than ever (Jawad et al., arXiv 2026). Most web application breaches exploit not exotic zero-days but the same handful of well-understood vulnerability classes that have topped the OWASP Top 10 for years: injection flaws, broken authentication, misconfigured security controls, and unpatched dependencies. This checklist covers the controls that actually move the needle against those threats.

Understanding the Threat Model Before You Harden

Hardening without a threat model is guesswork. Before running through any checklist, it is worth being explicit about what you are protecting, who realistically targets it, and what the business impact of each failure mode would be. The OWASP risk framework breaks this down into threat agents, attack vectors, security weaknesses, and business impact — the diagram below illustrates how these flow together.

For most web applications, the realistic threat agents are automated scanners, opportunistic script kiddies, credential-stuffing bots, and — for higher-value targets — motivated adversaries with specific objectives. The attack surfaces they exploit most are input handling (injection), authentication endpoints (brute force, credential stuffing), third-party dependencies (supply chain), and exposed internal functionality (broken access control). This checklist is organized around closing those specific paths.

Image: 2010-T10-ArchitectureDiagram — Neil Smithline (CC BY-SA 3.0), via Wikimedia Commons

Input Validation and Injection Prevention

Injection vulnerabilities — SQL injection, command injection, LDAP injection, and cross-site scripting (XSS) — consistently rank at the top of the OWASP list because they are both common and high-impact. Preventing them is not complicated, but it requires discipline applied to every input path, not just the obvious ones.

• Use parameterized queries or prepared statements everywhere. Never build SQL queries by concatenating user input. This applies equally to ORM queries when you drop to raw SQL for performance — parameterize those too.
• Validate input on the server side, always. Client-side validation improves user experience but provides zero security. Every input that reaches your server must be validated against an explicit allowlist of acceptable values, formats, and lengths.
• Encode output contextually. HTML-encode for HTML contexts, JavaScript-encode for JS contexts, URL-encode for URLs. Different contexts require different encoding — using the wrong one leaves gaps. Templating libraries like Jinja2, Thymeleaf, and React's JSX do this automatically when used correctly; do not bypass them with raw HTML concatenation.
• Sanitize HTML content explicitly. If your application must accept and render user-supplied HTML (rich text editors, markdown renderers), use a vetted sanitization library such as DOMPurify rather than attempting to filter yourself. Home-rolled HTML sanitizers are almost always bypassable.
• Apply input length limits at the application layer. Do not rely solely on database column length constraints. Long inputs can trigger denial-of-service conditions in parsers before they ever reach the database.

Security Headers That Block Common Browser Attacks

HTTP security headers are among the highest-leverage, lowest-effort hardening controls available. They instruct browsers to enforce security policies that stop entire classes of attacks — XSS, clickjacking, MIME sniffing, and insecure resource loading — before they can be exploited. Most can be set in minutes via server configuration or middleware.

The Content Security Policy (CSP) header is the most powerful but also the most complex to configure correctly. Start with a report-only policy (Content-Security-Policy-Report-Only) to observe violations without breaking functionality, then tighten incrementally. Avoid 'unsafe-inline' for scripts — use per-request nonces or hashes instead.

Authentication, Sessions, and Access Control

Broken authentication and broken access control consistently rank among the highest-severity vulnerability categories because their impact is direct: an attacker who bypasses authentication gains whatever access the compromised account holds. The controls here are well-understood but still frequently misconfigured:

• Enforce multi-factor authentication (MFA) on all privileged accounts. Passwords alone are insufficient for admin accounts, service accounts, and any role with production access. TOTP-based MFA (e.g., TOTP apps) is a minimum; hardware security keys (FIDO2/WebAuthn) are better for high-value accounts.
• Hash passwords with a modern, purpose-built algorithm. bcrypt, scrypt, and Argon2id are appropriate choices. Never use MD5, SHA-1, or unsalted SHA-256 for passwords. Migrate legacy hashing schemes on next login — do not leave them in production.
• Implement proper session management. Generate session tokens with a cryptographically secure random source (at least 128 bits of entropy). Regenerate the session ID after login to prevent session fixation. Set HttpOnly, Secure, and SameSite=Strict (or Lax) on session cookies.
• Enforce access control at the server side on every request. Never rely on hidden form fields, obscured URLs, or client-side role checks to gate access to sensitive resources. Check authorization server-side on every request, not just at login time.
• Apply rate limiting to authentication endpoints. Brute force and credential stuffing attacks depend on making many requests. Rate limit by IP, by account, and globally on login, password reset, and account creation endpoints. Add a progressive delay on repeated failures.

Dependency Management and Supply Chain Risk

Modern web applications typically depend on hundreds of open-source packages, each a potential vector for vulnerabilities introduced either inadvertently or through malicious compromise. Supply chain attacks have become one of the fastest-growing threat categories, and the controls here require ongoing attention rather than a one-time fix:

• Maintain an up-to-date software bill of materials (SBOM). Know what you are running. Tools like npm audit, pip-audit, Snyk, and Dependabot can generate and continuously monitor dependency trees against known vulnerability databases.
• Pin dependency versions in production. Floating version ranges (^1.2.0, ~2.0) in production can silently introduce breaking or vulnerable changes on install. Lock files (package-lock.json, poetry.lock, Cargo.lock) provide reproducibility — commit them and enforce them.
• Minimize the dependency surface. Every dependency is a liability. Evaluate whether a library is truly necessary before adding it, and remove unused packages aggressively. A smaller dependency tree is a smaller attack surface.
• Verify package integrity with checksums or SRI. Use Subresource Integrity (SRI) for CDN-served assets. For packages, verify checksums where your package manager supports it.

Image: OWASP-ZAP — Fabiorahamim (CC BY-SA 4.0), via Wikimedia Commons

Automated Scanning: Making Hardening Continuous

Hardening is not a one-time event — it is an ongoing practice. Attack surfaces change with every deployment, dependency update, and configuration change. The tools that make continuous hardening practical:

• DAST (Dynamic Application Security Testing): Tools like OWASP ZAP, Burp Suite Community Edition, and Nikto test running applications for active vulnerabilities. ZAP in particular can be integrated into CI/CD pipelines to run automated scans against staging environments on every deployment.
• SAST (Static Application Security Testing): Tools like Semgrep, Bandit (Python), Brakeman (Rails), and SonarQube analyze source code for vulnerability patterns before the application runs. They catch injection sinks, insecure function calls, and hardcoded credentials.
• Secrets scanning: Tools like Gitleaks, Trufflehog, and GitHub's native secret scanning prevent API keys, passwords, and tokens from being committed to version control. Run them as pre-commit hooks and in CI.
• Infrastructure as Code (IaC) scanning: Tools like Checkov, KICS, and Terrascan scan Terraform, CloudFormation, and Kubernetes manifests for misconfigurations — overly permissive IAM roles, exposed ports, unencrypted storage — before they reach production.

Frequently Asked Questions

What is the single highest-impact hardening step for a small web application?

If forced to choose one, implement parameterized queries for all database interactions and enable HTTPS with HSTS. Injection vulnerabilities combined with credential exposure via insecure transport remain the most commonly exploited paths for small web applications. These two controls eliminate entire vulnerability classes rather than patching individual instances.

How often should we run security scans against our application?

At minimum, run DAST scans against staging on every production deployment. Run dependency audits daily via automated tooling (Dependabot, Renovate, or similar). Conduct a more thorough manual penetration test at least annually, or after any significant architectural change. The goal is to make security testing a routine part of the deployment pipeline rather than a periodic event.

Is a Web Application Firewall (WAF) a substitute for proper hardening?

No. A WAF is a valuable defense-in-depth layer that filters known attack patterns at the network edge, but it is not a substitute for secure coding practices. WAFs can be bypassed by attackers who understand their signature rules, they introduce latency and false positives, and they provide no protection against logical vulnerabilities, broken access control, or insecure business logic. Harden the application itself first; add a WAF as an additional layer.

We recommend working through this checklist in priority order: input validation and parameterized queries first, then security headers, then authentication hardening, then dependency management, then automated scanning. Organizations that implement these controls systematically eliminate the vast majority of exploitable web vulnerabilities — not because the threats disappear, but because the attack surface shrinks to the point where exploitation requires substantially more effort and sophistication than most attackers will invest.

Disclaimer: This article is for informational purposes only. Technology landscapes change rapidly; verify information with official sources before making technical decisions.