A different way to think about secure coding.

Start with the security property, then form the habit

Effective Secure Coding is built around secure habits. Each habit centers on a security property we want to preserve or enforce - and on making that property the natural way to write code.

This way of thinking sometimes leads me away from familiar secure-coding advice. Here is one example: "Use an ORM." That is common advice for preventing SQL injection.

My preferred habit is: Keep query structure and data structurally separate. Once I have that property, I can choose an interface that preserves it while still taking advantage of the database.

String concatenation breaks the boundary by inserting data directly into SQL code:

var sql = "SELECT * FROM Users WHERE Name = '" + name + "'";

An interpolation-aware database API can keep the value parameterized:

db.Users.FromSql(
    $"SELECT * FROM Users WHERE Name = {name}");

A SQL DSL can make the separation part of the query structure:

dsl.selectFrom(USER)
   .where(USER.NAME.eq(name))
   .fetch();

The latter two preserve the property I care about: the interface keeps query structure and data separate.

Why keep SQL visible?

So why do I prefer keeping SQL visible - through a DSL or parameterized SQL - instead of using an ORM? I want the database to participate in the design.

I approach databases as both a developer and a DBA. I want the database itself enforcing security and correctness where it can.

A FOREIGN KEY can make an invalid relationship impossible to store; a CHECK constraint can reject invalid state; and a UNIQUE constraint can enforce a rule correctly when requests race. Views can provide stable read interfaces while the schema evolves, while stored procedures can expose specific write capabilities without granting general table-update permission.

This application may transfer money. It may not arbitrarily change account balances.

SQL can change the shape of the solution

Consider a money transfer. An object-oriented persistence model naturally leads toward loading two account entities, changing both objects, and saving the changes:

var from = accountRepository.findById(fromId).orElseThrow();
var to   = accountRepository.findById(toId).orElseThrow();

from.setBalance(from.getBalance().subtract(amount));
to.setBalance(to.getBalance().add(amount));

accountRepository.save(from);
accountRepository.save(to);

The application now has several steps whose transaction and concurrency behavior must be correct. The relational model lets us think about the operation as a change to a set of rows:

UPDATE Account
SET Balance = Balance +
    CASE Id
        WHEN :from THEN -:amount
        WHEN :to   THEN  :amount
    END
WHERE Id IN (:from, :to);

-- Preconditions such as sufficient funds are omitted here for clarity.

With the appropriate preconditions and constraints, one business operation can become one atomic database statement. Keeping SQL visible keeps that design option visible too.

Keep dangerous flexibility behind a constrained interface

The same habit applies when SQL genuinely needs to be dynamic. The application can receive a constrained database operation instead of arbitrary write permission.

A stored procedure can accept a requested column, verify that the identifier exists in database metadata, safely quote it, keep values parameterized, and execute the resulting operation using narrowly scoped database permissions.

This keeps the dangerous capability behind a safer interface - a pattern that appears throughout Effective Secure Coding.

Why am I telling you this?

Because this is a sample of how the book approaches secure coding. Take familiar security advice and ask: What property actually makes this safe? Then ask: Which habit can make that property the natural way to write the code? Then preserve the useful capabilities underneath whenever you can.

Sometimes that leads directly to established best practice. Sometimes it leads somewhere more opinionated - such as my preference for a typed SQL DSL and a deliberately designed database API over an ORM.

The idea is to develop secure-coding habits you can reason from, so you can make good decisions when the framework, language, database, or threat changes.