Skip to content
Lesson 8 of 8

Secure Coding and Tools

10 min read

The Secure Coding Mindset

Throughout the course we have looked at vulnerability after vulnerability. This final lesson brings the defenses together into a coherent set of practices and tools. Secure coding is not a list of tricks, but a mindset: assuming that all input is potentially malicious, that all trust must be justified, and that security is a property you design in, not one you add at the end.

This mindset comes down to a handful of principles that recur in almost all the defenses we have studied. They are worth stating precisely, because they are the synthesis of the entire course:

  • Validate input. Never trust data that crosses a trust boundary. We saw this with injection: user data must not be interpreted as code.
  • Encode output. Treat every piece of data according to the interpreter it is headed to. This is the heart of the defense against XSS and against injection in general.
  • Deny by default. Access, routes, and capabilities should be closed unless explicitly granted. Broken access control almost always stems from an "allow by default".
  • Least privilege. Every component, user, and credential gets only what it strictly needs. It limits the blast radius of a compromised account or key.
  • Defense in depth. Do not bet on a single control. If one fails, another must contain the impact, so no single class of failure becomes catastrophic on its own.
  • Fail securely. On error, the system must land in the most restrictive state, never open the door. A catch that grants access "just in case" is a vulnerability.

If you internalize these principles, you will be able to reason about vulnerabilities you do not yet know, not just the ones in the current OWASP Top 10. Walk mentally back through the course with this lens: injection is solved with parameterization (separating code from data), XSS with contextual encoding, authentication flaws with rigorous credential and session management, broken access control with server-side verification on every object, misconfiguration with hardening and deny-by-default, and SSRF and vulnerable components with destination validation and dependency management. Each defense is a principle applied to a context. Security changes; the principles remain.

Input Validation and Output Encoding

The two most cross-cutting defenses deserve a joint look. Input validation consists of checking that the data entering the application meets expectations: type, format, length, and range. The most robust validation uses allow-lists (define what is valid and reject everything else) instead of deny-lists (trying to enumerate the bad, which always leaves gaps). Validation must happen on the server, remembering that client validation is only cosmetic and can be bypassed with any proxy.

Output encoding is the other side: handling data correctly when it leaves the application toward an interpreter, whether the browser, a database, or a shell. It is key to understand that validation and encoding solve different problems and complement each other: validation rejects malformed data, while encoding neutralizes dangerous data in the context where it is used. A value can be valid (a name with quotes is a legitimate name) and still require encoding when inserted into HTML or SQL.

The problem: trusting unvalidated input

Consider a registration handler in Node/Express that trusts the request body. Validation is lax or nonexistent, and at best it leans on an ad-hoc deny-list that tries to enumerate what is forbidden:

// VULNERABLE: no schema, trusts the body shape and uses a fragile deny-list
app.post("/api/register", async (req, res) => {
  const { email, age, role } = req.body;

  // Ad-hoc deny-list: always leaves gaps (uppercase, unicode, etc.)
  if (email && email.includes("<script>")) {
    return res.status(400).send("Invalid input");
  }

  // `age` may arrive as string, object, or array; `role` unrestricted
  await createUser({ email, age, role });
  res.status(201).send("User created");
});

There are several problems here: age's type is not validated, role is not restricted (an attacker could send role: "admin", a case of mass assignment and privilege escalation), and the email check is a deny-list that is trivially bypassed. The root cause is trusting the shape of the input.

The fix: schema-based allow-list

The solution is a declarative allow-list: define a schema that describes exactly what is acceptable and reject anything that does not fit. With a schema validation library like zod (or Joi), this is concise and runs on the server:

import { z } from "zod";

const RegisterSchema = z.object({
  email: z.string().email().max(254),
  age: z.number().int().min(18).max(120),
  role: z.enum(["user", "editor"]), // 'admin' is NOT client-assignable
}).strict(); // reject any undeclared field

app.post("/api/register", async (req, res) => {
  const result = RegisterSchema.safeParse(req.body);

  if (!result.success) {
    // Fail securely: reject without leaking internal details
    return res.status(400).json({ error: "Invalid registration data" });
  }

  await createUser(result.data); // already typed and validated data
  res.status(201).send("User created");
});

The schema turns validation into an explicit allow-list: email must be a valid, bounded address, age an integer in a reasonable range, and role can only be one of the permitted values. The .strict() rejects unexpected fields, closing the door to mass assignment. When validation fails, we fail securely by returning a generic error. Notice that we do not try to "clean" the input here: we reject it if it does not fit, which is safer and simpler.

Integrating reminder: encoding is still required

Validating does not exempt you from encoding on output. Even if email passed the schema, when using it you must respect the destination context: parameterization toward the database, contextual encoding toward the HTML.

// SQL: parameterization (code-data separation), never concatenation
await db.query("SELECT id FROM users WHERE email = $1", [data.email]);

// HTML: let the framework encode by context (React escapes by default);
// avoid innerHTML / dangerouslySetInnerHTML with user data.

Validation and encoding are distinct layers of the same defense in depth: the first decides whether the data gets in; the second, how it is represented without changing meaning as it crosses into an interpreter.

Tools: Burp Suite and OWASP ZAP

To find vulnerabilities you need tools that let you see and manipulate traffic. Burp Suite is the industry-standard intercepting proxy for web security testing. It sits between the browser and the server and lets you inspect every request and response, and modify them on the fly. Its key modules are:

  • Repeater: resends a request over and over with small variations to observe how the server responds. It is the ideal tool for testing hypotheses manually and in a controlled way.
  • Intruder: automates sending requests by systematically varying parameters, useful for targeted testing over a specific field.
  • Scanner: in the professional version, an automated scanner that crawls the application looking for known vulnerability patterns.

OWASP ZAP (Zed Attack Proxy) is the free and open-source alternative, maintained by the OWASP foundation. It offers similar proxy functionality, a spider to discover content by following links, and passive scanning (observes the traffic you generate normally and flags indicators without sending attacks) and active scanning (sends crafted requests to provoke revealing behaviors). It is excellent both for learning and for integrating into automated pipelines. Both tools are fundamental for targeted manual testing, especially for logic vulnerabilities like broken access control and IDOR, which automatic scanners can hardly detect on their own because they require understanding business intent.

SAST, DAST and SCA: Automated Analysis

Automated security analysis relies on three complementary approaches that cover different moments and angles.

SAST (Static Application Security Testing) analyzes the source code without executing it, looking for insecure patterns like SQL concatenation, use of dangerous functions, or embedded secrets. Its advantage is that it runs early, even before deploying, and points to the exact line of the problem; its limitation is that it generates false positives and does not see flaws that depend on the runtime environment. Tools like Semgrep or CodeQL fit here and integrate well into every commit.

DAST (Dynamic Application Security Testing) tests the running application, sending it requests and observing the responses; OWASP ZAP and the Burp scanner are DAST tools. It sees the application as it actually works, including behaviors that depend on the configuration and environment, but it does not point to the line of code and may not cover all paths.

SCA (Software Composition Analysis) focuses on third-party dependencies, comparing your package tree against databases of known vulnerabilities. We saw it in the previous lesson on vulnerable components; tools like Dependabot or Snyk automate this monitoring and propose updates.

The ideal is to combine the three: SAST and SCA integrated into the CI/CD pipeline for early feedback on every commit, and DAST over deployed environments where the application actually runs. No tool replaces the others or human judgment: scanners find the known and repetitive, but logic flaws still require review and manual testing.

Integrating Security into the Lifecycle

Effective security is not a final phase or a one-off audit, but a continuous practice integrated across the entire development lifecycle, known as DevSecOps or "shift left": moving security toward the early stages, where fixing is cheaper. In practice, this means training developers, modeling threats during design, integrating SAST/SCA into every commit, running DAST in testing, and performing code reviews with a security focus.

Lean on reference resources: the OWASP Top 10 as a map of priority risks, the OWASP ASVS as a verification standard with concrete per-level requirements, the OWASP cheat sheets as practical recipes, the WSTG (Web Security Testing Guide) as a testing methodology, and the CWE catalog to classify weaknesses in a common language. Complement the automated tools with periodic manual penetration testing and, when the scope justifies it, responsible disclosure or bug bounty programs.

Prevention Checklist

This is the course's master checklist: it walks through the eight areas we studied and condenses the actionable part of each.

  • Attack surface: minimize exposed endpoints, functions, and data; remove what is unused; know and document your surface.
  • Injection: always use parameterized queries or an ORM; never build commands by concatenating user input; validate input with allow-lists.
  • XSS: encode output according to context; trust the framework's escaping; avoid innerHTML/dangerouslySetInnerHTML with user data; apply a CSP as defense in depth.
  • Authentication: store passwords with slow hashing (bcrypt/argon2); offer MFA; manage sessions with secure cookies; apply rate limits and lockouts against brute force.
  • Access control: deny by default; verify authorization on the server for every object and action; never trust client-supplied identifiers (avoid IDOR).
  • Misconfiguration: harden defaults; disable the unnecessary; manage secrets outside the code; send security headers; do not leak details in errors.
  • SSRF and components: validate and restrict destinations of outbound requests with allow-lists; keep dependencies updated and monitored with SCA.
  • Secure coding and tools: validate input and encode output as a habit; apply the six principles in every decision; integrate SAST, DAST, and SCA into the pipeline and complement with human review.

Remember: the goal is not to reach perfect security (which does not exist), but to continuously raise the cost for the attacker while you reduce your surface and your response time. With the foundations of this course, you have the framework to build defensible web applications.