The same refactor — bootstrap module delegating catalog, schema, and volume creation to Spark SQL — shipped with a SQL literal-escaping utility, handling single quotes and backslashes in the strings passed into raw statements (comments, storage paths). It was written. It worked. Then I reverted it before it was ever committed.
Not because it was wrong, but because of one question I asked before committing it — the kind that feels almost rude to ask of security code: where do these strings actually come from?
# Every string reaching a raw SQL statement traced back to here:
class BootstrapConfig(BaseModel):
catalog: str
comment: str
storage_path: str
cfg = BootstrapConfig.model_validate(startup_args) # typed, validated at boot
spark.sql(f"CREATE CATALOG IF NOT EXISTS {cfg.catalog} COMMENT '{cfg.comment}'")
# no request body, no user field, no external API anywhere in this path Every value originated in a typed configuration model, validated at application startup. There was no code path that carried user-supplied input into these statements. The attack surface the escaping defended against did not exist in this system.
You can’t exploit a boundary that isn’t there.
And the escaping wasn’t free. The utility has to stay correct as string types evolve, every caller has to remember to apply it, every reviewer has to check that they did. None of that cost buys anything when there’s no threat to absorb — worse, it signals a protection that isn’t real, the kind that invites you to relax. So it went, with the reasoning written into the decisions file so the next reader doesn’t reconstruct it. (Same session, same instinct: a bootstrap "class" with no state and no lifecycle became a plain function — question the premise before you build on it.)
The principle I carry out of it: security code earns its keep by matching a real threat model, not by looking defensive. Model the input path before you harden it — and when the threat isn’t there, the most secure move is to delete the code that pretended it was.