🏗️ Secure by Design
Security built in from the start — not bolted on after breaches happen⏱ ~3 min
Imagine a homebuilder who sells houses with no locks, no window latches, and no door frames — claiming 'buyers can add security themselves.' That's absurd. We expect builders to include basic security as part of the structure. Yet for decades, software companies shipped products with default credentials of 'admin/admin,' no automatic updates, and known vulnerabilities — expecting users to secure them. Secure by Design is the movement that says: manufacturers bear primary responsibility for the security of their products.
Secure by Design: Three Principles (CISA, 2023)
- 1.Take ownership for security outcomes — companies should not release products with known vulnerabilities and expect customers to fix them. Requiring users to set a strong password at setup (no default credentials) is the manufacturer taking responsibility.
- 2.Be transparent and accountable — disclose vulnerabilities promptly using coordinated disclosure; clearly explain updates and what they fix; be honest about risk. Hiding a security problem and quietly patching it (while customers remain vulnerable) violates this principle.
- 3.Build security into organizational structure — the CISO must have authority to halt unsafe product releases; security checks must be embedded into every stage of development; security can't be a team you consult after decisions are made.
Secure by Default
A product is 'secure by default' if it can be safely used straight out of the box without any security configuration by the user. This means: no default credentials (force unique passwords at setup), automatic security updates enabled, unnecessary features/ports disabled by default, encryption on by default.
Input Sanitization — Never Trust User Input
The root cause of SQL injection, XSS, buffer overflow, and directory traversal attacks is the same: the application trusted user input and treated it as commands/code instead of data. Input sanitization is the defense.
| Dangerous Input | Attack Type | System Response Should Be | Why |
|---|---|---|---|
| admin' OR '1'='1 | SQL Injection | Reject or sanitize — the quote is a SQL control character | Input should never become part of a SQL statement |
| <script>alert('XSS')</script> | Cross-Site Scripting | Encode output — < becomes < and > becomes > | Angle brackets rendered as HTML tags execute JavaScript in victim's browser |
| ../../etc/passwd | Directory Traversal | Reject — ../ attempts to navigate outside intended directory | Lets attacker read files outside the web application's folder |
| O'Brien | NOT an attack | Accept — this is a legitimate name | The apostrophe is real data; parameterized queries handle it safely without rejecting |
The Two Defenses: Sanitize or Reject
- •Parameterized queries (best for SQL) — input passed as a parameter, never concatenated into SQL text; the database treats it as data regardless of content; O'Brien works fine
- •Output encoding (best for XSS) — encode special characters before displaying user input in HTML; < becomes < — no script can execute
- •Input validation — check type, length, and format before processing; a username field should only accept alphanumeric characters; reject everything else
- •The golden rule: never concatenate user input directly into SQL, HTML, or system commands
A company ships a home router with: • Default username: admin • Default password: admin • Automatic security updates: OFF • Remote management: enabled on port 8080 • UPnP: enabled (allows devices to open ports automatically) Which Secure by Design principles does this violate, and what would a Secure by Default configuration look like?