SECURE BY DESIGN: MASTER GUIDELINES AND CWE MITIGATION
This document establishes the master guidelines for software development under a "Secure by Design" approach. In a landscape where code volume grows exponentially, it is imperative to adopt patterns that reduce risk early, before vulnerabilities become exploitable in production environments.
Focus: Secure by Design · Zero Trust in Code
Prohibited: Hardcoding credentials in repositories
Environment: Continuous Integration (SDLC) assisted by AI and cloud context.
// Non-technical explanation
Building software without thinking about security is like manufacturing a car without brakes and adding them after it's already on the street. "Secure by Design" means thinking about the brakes, the chassis, and the airbags from the first paper sketch, not as a patch added at the very end.
01. THE SECURE DESIGN BLUEPRINT
Security does not begin in the code, but in the evaluation of the environment and the nature of the data. Before writing business logic, three critical design questions must be answered:
1. Surface Exposure: Will the application be publicly exposed to the Internet or restricted to internal traffic? Attack vectors and entry points must be modeled based on this exposure.
2. Data Sensitivity: What type of information will the system process? Handling PII, PHI, or financial data dictates specific compliance and control levels.
3. Identity and Ownership: Who is the system owner, and which identities (users or services) are explicitly authorized to interact with it?
Security in API Design: Mandatory use of OAuth 2.0 for third-party integrations, JSON Web Tokens (JWT) for stateless authentication, and strict implementation of MFA (Multi-Factor Authentication) as a depth defense layer.
Resilience Patterns: Assume any input can be malicious. Implement Schema Enforcement (e.g., JSON Schema), Rate Limiting/Throttling to mitigate DoS, and Safe Failure Modes (sanitize logs and stack traces to prevent CWE-209).
02. CENTRALIZED SECRET MANAGEMENT
The use of "hardcoding" for API keys, certificates, passwords, or any credentials in source code or configuration files is strictly prohibited.
Applications must be designed to retrieve secrets dynamically at runtime using specialized vaults. The use of AWS Secrets Manager or Azure Key Vault is required to centralize management, rotation, and auditing, ensuring secrets never reside in the version control system (Git).
03. INJECTION VULNERABILITIES (CWE TOP 25)
Injection weaknesses remain the most critical attack vector. Mitigation requires strict coding patterns.
| Name / CWE | Impact | Mitigation Strategy |
|---|---|---|
| XSS (CWE-79) | Session hijacking, malicious redirects. | Use text APIs (textContent), not HTML execution. |
| SQL Injection (CWE-89) | Unauthorized DB access or alteration. | Prepared statements or mandatory ORMs. |
| Code Injection (CWE-94) | Total system compromise. | Avoid eval(), use allow-lists. |
| Command Injection (CWE-77) | Arbitrary OS command execution. | Pass arguments as lists, avoid shell use. |
// Risky Pattern:
document.getElementById("output").innerHTML = comment;
// Solution (Fix):
document.getElementById("output").textContent = comment;
// Risky Pattern:
const result = eval(expr);
// Solution (Fix): Strict validation and type conversion
if (!/^\d+$/.test(expr)) {
return res.status(400).send("Invalid input");
}
const result = Number(expr);
# Risky Pattern:
cursor.execute(f"SELECT * FROM users WHERE username = '{username}'")
# Solution (Fix):
cursor.execute(
"SELECT * FROM users WHERE username = %s",
(username,)
)
# Risky Pattern:
subprocess.check_output(f"ping {host}", shell=True)
# Solution (Fix):
subprocess.check_output(["ping", host])
04. ACCESS CONTROL AND FLOWS
Missing Authorization (CWE-862): Occurs when there is no permission check. Incorrect Authorization (CWE-86