Secure Coding: Write Code That Resists Attacks

Secure coding means writing software so that untrusted input cannot change what the code does beyond its intent. In practice it means validating the shape of input at trust boundaries, using safe APIs at sinks such as SQL, HTML, shell and the file system, checking authorisation on the server and proving each defence with a test.

Keep the query text constant and pass values as parameters, for example conn.execute("SELECT id FROM customers WHERE email = ?", (email,)) with sqlite3. The driver binds the value separately, so it can never become SQL. Column names cannot be bound; map user choices to an allow-list instead.

No. Validation checks that data has the expected shape, but legitimate data such as an address with an apostrophe can still contain characters that are dangerous at a particular sink. Validation is a supporting layer; the decisive defence is the sink-specific API, such as placeholders for SQL or auto-escaping for HTML.

Avoid client-supplied file names where possible and map IDs to files on the server. If a name must come from the client, allow only a strict pattern, resolve it with path.resolve against the base folder and check that the result starts with the base folder plus path.sep. Resolve symbolic links if they can occur.

A source is where data you do not control enters the code, such as request parameters, headers, uploaded files or stored user data. A sink is an operation where that data can change behaviour, such as a SQL query, a shell command, HTML output or a file read. Reviewers find sinks first and trace values back to their sources.

Write a unit test for the property the fix protects, run it against the vulnerable version and confirm that it fails, then confirm that it passes on the fixed version. Keep it in the test suite so the build fails if someone reintroduces the vulnerable pattern.