security-and-hardening

Security and Hardening

Overview

Security-first development practices for web applications. Treat every external input as hostile, every secret as sacred, and every authorization check as mandatory. Security isn't a phase — it's a constraint on every line of code that touches user data, authentication, or external systems.

When to Use

• Building anything that accepts user input
• Implementing authentication or authorization
• Storing or transmitting sensitive data
• Integrating with external APIs or services
• Adding file uploads, webhooks, or callbacks
• Handling payment or PII data

Process: Threat Model First

Controls bolted on without a threat model are guesses. Before hardening, spend five minutes thinking like an attacker:

1. Map the trust boundaries. Where does untrusted data cross into your system? HTTP requests, form fields, file uploads, webhooks, third-party APIs, message queues, and LLM output. Every boundary is attack surface.
2. Name the assets. What's worth stealing or breaking? Credentials, PII, payment data, admin actions, money movement.
3. Run STRIDE over each boundary — a quick lens, not a ceremony:

Threat	Ask	Typical mitigation
Spoofing	Can someone impersonate a user/service?	Authentication, signature verification
Tampering	Can data be altered in transit or at rest?	Integrity checks, parameterized queries, HTTPS
Repudiation	Can an action be denied later?	Audit logging of security events
Information disclosure	Can data leak?	Encryption, field allowlists, generic errors
Denial of service	Can it be overwhelmed?	Rate limiting, input size caps, timeouts
Elevation of privilege	Can a user gain rights they shouldn't?	Authorization checks, least privilege

1. Write abuse cases next to use cases. For each feature, ask "how would I misuse this?" — then make that your first test.

If you can't name the trust boundaries for a feature, you're not ready to secure it. This is OWASP A04: Insecure Design — most breaches begin in design, not code.