Web Security Best Practices That Actually Stop Breaches

The MOVEit Breach Started With One Overlooked Web Flaw

In 2023, a single SQL injection vulnerability in the MOVEit Transfer web application led to one of the largest mass exploitation events in history. Over 2,600 organizations were compromised. Sensitive data from government agencies, banks, and healthcare providers was exfiltrated by the Cl0p ransomware gang — all because web security best practices weren't followed on a single file transfer interface.

I've spent over two decades watching organizations invest millions in perimeter defenses while leaving their web applications wide open. The pattern never changes. The Verizon 2024 Data Breach Investigations Report confirmed that web applications were the primary attack vector in 26% of all breaches. That number has been climbing for years.

This post isn't a theoretical overview. It's a specific, prioritized list of web security best practices drawn from real incidents, real attack patterns, and the frameworks that actually work. If you run a website, a web app, or an API — this is your checklist.

Why Most Web Security Fails Before It Starts

Here's what actually happens in most organizations. A development team ships a web application under deadline pressure. Security gets bolted on afterward — if it gets bolted on at all. The security team runs a scan, finds 200 findings, and the dev team fixes the 10 easiest ones.

That gap between "we scanned it" and "we secured it" is where threat actors live. They don't need zero-days. They need one unvalidated input field, one misconfigured header, one exposed admin panel. The OWASP Top 10 hasn't changed dramatically in a decade because organizations keep making the same mistakes.

The real issue isn't technical knowledge. It's organizational discipline. Web security best practices only work when they're baked into your development lifecycle, not stapled to the end of it.

Input Validation: The First Line of Defense You're Probably Skipping

SQL injection has been a known vulnerability since the late 1990s. It was behind the MOVEit breach. It was behind the Heartland Payment Systems breach that exposed 130 million credit card numbers. And I guarantee you, right now, someone on your team is concatenating user input directly into a database query.

Server-Side Validation Is Non-Negotiable

Client-side validation is a user experience feature. It is not a security control. Every input that touches your server must be validated server-side against a strict allowlist. That means defining exactly what characters, lengths, and formats are acceptable — and rejecting everything else.

Parameterized Queries, Every Time

Use parameterized queries or prepared statements for every database interaction. No exceptions. No "we'll fix it later." ORMs help, but they're not magic — you still need to understand what queries they generate.

Encode Output Contextually

Cross-site scripting (XSS) remains in the OWASP Top 10 because developers forget that output encoding depends on context. Data going into HTML needs HTML encoding. Data going into JavaScript needs JavaScript encoding. Data going into a URL needs URL encoding. One function does not fit all contexts.

HTTP Security Headers Most Sites Still Get Wrong

I regularly audit web applications for organizations that consider themselves security-conscious. At least half of them are missing critical HTTP security headers. These headers cost nothing to implement and block entire categories of attacks.

The Headers You Need Right Now

Content-Security-Policy (CSP): Restricts which scripts, styles, and resources can load. A properly configured CSP can neutralize most XSS attacks. Start with a report-only policy, then tighten.
Strict-Transport-Security (HSTS): Forces HTTPS connections and prevents protocol downgrade attacks. Set max-age to at least one year and include subdomains.
X-Content-Type-Options: Set to "nosniff." Prevents browsers from MIME-type sniffing, which attackers use to execute malicious files.
X-Frame-Options: Set to "DENY" or "SAMEORIGIN" to prevent clickjacking attacks. CSP's frame-ancestors directive is the modern replacement, but both should be present for backward compatibility.
Referrer-Policy: Set to "strict-origin-when-cross-origin" or stricter. Prevents sensitive URL parameters from leaking to third parties.
Permissions-Policy: Restricts access to browser features like camera, microphone, and geolocation. If your app doesn't use them, disable them explicitly.

CISA's guidance on web security reinforces these recommendations. You can find their secure-by-design principles at cisa.gov/securebydesign.

Authentication and Credential Theft: The $4.88M Weak Spot

IBM's Cost of a Data Breach Report 2024 put the global average breach cost at $4.88 million. Stolen or compromised credentials were the most common initial attack vector, and breaches caused by credential theft took the longest to identify and contain — an average of 292 days.

Multi-Factor Authentication Isn't Optional Anymore

If your web application supports user accounts and you haven't implemented multi-factor authentication, you're operating with a known, exploitable vulnerability. MFA blocks over 99% of automated credential stuffing attacks according to Microsoft's own research. Prefer hardware tokens or authenticator apps over SMS-based MFA, which is vulnerable to SIM swapping.

Password Policies That Reflect Reality

NIST's Digital Identity Guidelines (SP 800-63B) changed the game. Stop forcing password rotations every 90 days. Stop requiring arbitrary complexity rules. Instead: enforce a minimum of 8 characters (prefer 15+), check passwords against known breach databases, and let users use passphrases. You can review the full guidance at pages.nist.gov/800-63-3/sp800-63b.html.

Session Management Done Right

Generate cryptographically random session tokens. Set the Secure, HttpOnly, and SameSite attributes on all session cookies. Implement absolute session timeouts — not just idle timeouts. Invalidate sessions server-side on logout. And never, ever put session tokens in URLs.

What Are Web Security Best Practices?

Web security best practices are a set of technical and organizational controls designed to protect web applications, APIs, and their underlying data from unauthorized access, data breaches, and exploitation. They include input validation, secure authentication, HTTP security headers, encryption in transit and at rest, regular patching, security awareness training, and adopting a zero trust architecture. These practices are informed by frameworks like the OWASP Top 10, NIST Cybersecurity Framework, and CISA's secure-by-design principles.

Zero Trust Architecture: Stop Trusting Your Own Network

The old model — hard perimeter, soft interior — is dead. If a threat actor compromises one web server, they shouldn't be able to pivot to your database server, your internal APIs, or your admin tools. Zero trust means verifying every request, regardless of where it originates.

Apply Least Privilege at Every Layer

Your web application's database account should have the minimum permissions necessary. Your API service accounts should only access the endpoints they need. Your admin panels should be on separate network segments with additional authentication requirements. Every layer should assume the others have been compromised.

Microsegmentation Matters

Segment your web tier from your application tier from your data tier. Use network policies or service mesh controls to enforce allowed communication paths. When the next vulnerability hits — and it will — microsegmentation limits the blast radius.

Patching: The Boring Practice That Prevents Catastrophe

The Equifax breach of 2017 that exposed 147 million records happened because of an unpatched Apache Struts vulnerability. The patch had been available for two months before the breach. Two months. I've seen this pattern repeated dozens of times in my career.

Establish a patch management cadence. Critical web framework and server vulnerabilities get patched within 48 hours. High-severity findings within a week. Track your patching metrics and hold teams accountable. Automated dependency scanning tools like Dependabot or Renovate can flag vulnerable libraries the moment a CVE is published.

You can implement every technical control on this list and still get breached because someone in your organization clicked a phishing email and entered their credentials on a fake login page. The Verizon DBIR consistently shows that social engineering and phishing are involved in a significant percentage of breaches — and web applications are frequently the target of credential phishing campaigns.

Build a Human Firewall

Technical controls and security awareness must work together. Your employees need to recognize phishing attempts, pretexting, and social engineering tactics. Regular phishing simulation exercises are one of the most effective ways to reduce click-through rates and build organizational resilience.

If you're looking to build this capability, explore the phishing awareness training for organizations at phishing.computersecurity.us. It covers real-world phishing scenarios and gives your team hands-on practice identifying threats before they click.

For a broader foundation in security awareness — covering credential theft, ransomware, physical security, and more — the cybersecurity awareness training at computersecurity.us is built for exactly this purpose.

Modern web applications are really API applications. Your single-page app talks to a REST or GraphQL API. Your mobile app talks to the same API. Your partners integrate via API. And most organizations secure their APIs far less rigorously than their traditional web pages.

Authenticate and Authorize Every API Call

Use OAuth 2.0 with short-lived access tokens. Validate JWTs properly — check the signature, the issuer, the audience, and the expiration. Implement rate limiting to prevent abuse. And apply authorization checks at the object level, not just the endpoint level. Broken object-level authorization (BOLA) is the number one API vulnerability according to the OWASP API Security Top 10.

Don't Expose More Than You Should

API responses should return only the fields the client needs. Verbose error messages, stack traces, and internal identifiers are gifts to attackers performing reconnaissance. Use API gateways to enforce schemas and strip sensitive data before it leaves your infrastructure.

Logging, Monitoring, and Incident Response

If you can't detect a breach, you can't respond to one. The FBI's Internet Crime Complaint Center (IC3) at ic3.gov receives hundreds of thousands of complaints annually, and delayed detection is a recurring theme in the most damaging cases.

Log What Matters

At minimum, log all authentication events (successes and failures), authorization failures, input validation failures, and administrative actions. Send logs to a centralized SIEM. Set alert thresholds for brute force attempts, credential stuffing patterns, and unusual data access volumes.

Have a Plan Before You Need One

Your incident response plan should specifically address web application compromises. Who gets notified? How do you isolate a compromised server? Where are your backups, and have you tested restoring them? If you can't answer these questions in under 60 seconds, your plan isn't ready.

The Deployment Pipeline Is a Security Control

Your CI/CD pipeline should include static application security testing (SAST) and dynamic application security testing (DAST) at every build. Fail the build on critical findings. Scan container images for known vulnerabilities before they reach production. Sign your artifacts and verify signatures on deployment.

Infrastructure as code should be scanned for misconfigurations — open S3 buckets, permissive security groups, and default credentials are still among the most common findings in cloud-hosted web applications.

Your 10-Point Web Security Action Plan

Here's what to do this week — prioritized by impact:

1. Enable MFA on every account that accesses your web application's admin panel, hosting provider, and code repository.
2. Add HTTP security headers — CSP, HSTS, X-Content-Type-Options, X-Frame-Options — to every response.
3. Audit your input validation. Find every point where user input touches a database query, a command, or a rendered page. Fix them.
4. Patch your web frameworks and dependencies to the latest stable versions today.
5. Implement rate limiting on authentication endpoints and APIs.
6. Review your API authorization logic. Test for broken object-level authorization specifically.
7. Deploy centralized logging with alerts for authentication anomalies.
8. Run a phishing simulation to baseline your organization's susceptibility to credential theft.
9. Segment your web infrastructure — separate your web tier, app tier, and data tier.
10. Train your team. Technical controls fail when people don't understand the threats they face.

Web security best practices aren't a one-time project. They're an ongoing discipline that combines technical controls, organizational culture, and continuous training. The organizations that take them seriously don't end up in the headlines. The ones that don't — well, you've read those stories.

Start with the fundamentals. Build from there. And make sure your entire team — not just your developers — understands the role they play in keeping your web applications secure.