Security is a process, not a scan
The security-theater version: run a scanner, fix the reds, claim secure. The real version: security decisions made during the build, how data is validated, what runs with which privileges, where secrets live, what the dependencies bring with them. Scans have a place (they catch known classes), but a site is only as secure as the decisions nobody scanned. This page lists those decisions as they are actually practiced in builds here; the standing services live at website security and the incident path at hacked-recovery.
The build-time practices
- Input validation everywhere. Every field the user touches is checked: type, length, format, range, server-side, not just browser-side. Most injection and abuse begins as "the form accepted whatever."
- Parameterized queries. Database access never concatenates user input into SQL. This one practice retires the oldest attack class on the internet, and it is a coding standard, not a tool.
- Least privilege. Database users that can only do what the app needs; admin accounts as humans, not shared logins; API keys scoped to the minimum; file permissions as tight as function allows. When something is compromised, least privilege is the difference between a bad afternoon and a catastrophe.
- Dependency hygiene. Every library is a supply-chain decision: pinned versions, audited updates, and removal of what is unused. Abandoned dependencies are unpatched doors.
- Secrets management. API keys and credentials in environment configuration and vaults, never in code, never in repositories, never in prompts to AI tools (the AI process hard-codes this).
- Headers and transport. TLS everywhere, security headers set, cookies flagged properly. The mixed-content class dies here.
- Failed-login and abuse paths. Rate limits, lockouts, and monitoring on the doors, because bots probe every site on the internet continuously, and the log that notices is the cheap defense.
The honest boundaries
Build-time security makes you a hard target, not an invulnerable one. Zero-day vulnerabilities in dependencies, compromised employee machines, and social engineering all bypass code quality, which is why the maintenance loop (patching, monitoring, backups with restore tests) and the recovery policy are the other halves. Security is three legs: built-in, maintained, and recoverable. This page is the first leg; the brief starts the other two when your site is missing them.