Skip to content

Chapter 3 of 6

Defensive Coding Practices

Most web vulnerabilities can be prevented at the point where untrusted data meets code. Input validation is the first line: incoming data should be checked for expected type, format, length, and constraints before it is processed further. Client-side validation still has a place because it improves user experience, but it must never be relied on for security — attackers bypass it trivially. Where possible, allowlists (permitting only known-good values) are far safer than blocklists (rejecting known-bad patterns), because allowlists fail closed against novel attacks.

For SQL and similar databases, parameterized queries (also called prepared statements) separate the query structure from the data: the database compiles the SQL once, and user input is bound as values rather than spliced in as code. This single discipline reliably prevents SQL injection. For output, escaping ensures untrusted content is treated as data, not executable code. HTML escaping neutralizes characters for safe insertion into HTML text or attributes, while JavaScript escaping does the same inside JS string literals or blocks — confusing the two is a common XSS vector. Correct Content-Type headers also matter: without X-Content-Type-Options: nosniff, browsers may MIME-sniff a response and interpret a text/plain upload as HTML or script.

Beyond code-level controls, Content Security Policy (CSP) lets a server instruct the browser to restrict what scripts, styles, and resources can load. A strict policy avoids 'unsafe-inline' (which neuters most XSS protection) and 'unsafe-eval' (which permits eval and string-based code construction); nonce-based scripts and 'strict-dynamic' trust scripts loaded by a nonce-bearing script, avoiding brittle CDN allowlists. Subresource Integrity (SRI) hashes verify that a fetched script or stylesheet matches a known digest, so a compromised CDN cannot serve altered code. For third-party scripts specifically, the safest pattern is to pin exact versions, serve them yourself when possible, isolate them in sandboxed iframes with a strict CSP, and review what data they collect. None of these replaces secure code — a Web Application Firewall (WAF) inspects HTTP traffic for known-bad patterns but can be bypassed with encoding, parameter pollution, or novel payloads and adds latency and false positives — but together they form effective defense in depth.

All chapters
  1. 1Foundations of Web Security
  2. 2Common Web Vulnerabilities
  3. 3Defensive Coding Practices
  4. 4Authentication, Sessions, and Password Security
  5. 5HTTP Headers, CORS, and Transport Security
  6. 6Industry References and Token-Based API Security

Drill it

Reading is not remembering. These come from the Web Security deck:

Q

What is web security?

Web security is the practice of protecting web applications, users, and data from malicious access, misuse, or disruption.

Q

Why is web security important?

Security failures damage trust, expose sensitive data, and can create legal, financial, and operational harm.

Q

What is authentication?

Authentication verifies who a user or system claims to be.

Q

What is authorization?

Authorization determines what an authenticated user is allowed to access or do.