Security in Software Development

Security in Software Development

Security cannot be bolted on after the fact. An application built without security considerations has structural vulnerabilities that are expensive to fix — if fixable at all — once the system is in production. Secure software development integrates security at every stage: design, implementation, testing, and deployment.

Threat Modeling

Threat modeling asks: what could go wrong? Before writing code for a new feature, consider:

STRIDE (Microsoft's threat categorization):

• Spoofing: impersonating another user or service
• Tampering: modifying data or code without authorization
• Repudiation: denying actions that occurred (no audit trail)
• Information Disclosure: exposing private data to unauthorized parties
• Denial of Service: making a service unavailable
• Elevation of Privilege: gaining more access than intended

The process: draw a data flow diagram (components, data stores, external actors, data flows). For each flow and component, enumerate STRIDE threats. For each threat, determine a mitigation: authentication, input validation, audit logging, rate limiting, least privilege.

OWASP Top 10

The OWASP Top 10 represents the most common and impactful web security risks:

1. Broken Access Control: users access resources they should not (IDOR — Insecure Direct Object Reference, vertical/horizontal privilege escalation). Enforce authorization checks on every request. Never trust client-supplied IDs as authorization tokens.

2. Cryptographic Failures: sensitive data (passwords, credit cards, health records) exposed due to weak encryption, missing encryption, or misused cryptography. Encrypt data in transit (TLS everywhere) and at rest. Never roll your own crypto. Use bcrypt/Argon2 for passwords — never MD5 or SHA1.

3. Injection (SQL, NoSQL, OS command, LDAP): user input injected into commands or queries. Use parameterized queries. Never concatenate user input into SQL. Validate and sanitize all input.

4. Insecure Design: security requirements not considered during design. Threat model. Defense in depth. Assume breach. Secure defaults.

5. Security Misconfiguration: default credentials left unchanged, unnecessary features enabled, debug logging in production, verbose error messages exposing stack traces. Principle of least privilege in infrastructure. Disable what you don't need.

6. Vulnerable and Outdated Components: dependencies with known CVEs. Automated dependency scanning (Dependabot, Snyk). Keep dependencies updated.

7. Authentication Failures: weak passwords allowed, no multi-factor, session IDs exposed in URLs, sessions not invalidated after logout. Use proven authentication libraries. Implement MFA. Short session timeouts for sensitive operations.

8. Software and Data Integrity Failures: code or data pipeline integrity not verified; use code signing, artifact hashing, and verified build processes.

9. Logging and Monitoring Failures: attacks undetected due to insufficient logging. Log security events: authentication attempts, access control failures, input validation failures. Alert on anomalies. Retain logs for forensics.

10. Server-Side Request Forgery (SSRF): attacker tricks the server into making requests to internal services. Validate and restrict which URLs the server will request; use allowlists.

Secure Coding Practices

Input validation: validate all input at system boundaries. Length, type, format, and range. Reject, don't sanitize, malicious input where possible. Validation happens server-side — client-side validation is UX, not security.

Output encoding: encode output according to context. HTML encoding prevents XSS in HTML contexts. URL encoding prevents injection in URLs. SQL parameterization prevents SQL injection. JSON serialization prevents JSON injection. The context determines the encoding.

SQL injection prevention: always use parameterized queries or ORM methods that handle parameterization:

-- WRONG: vulnerable to injection
SELECT * FROM users WHERE email = '${userInput}'

-- CORRECT: parameterized
SELECT * FROM users WHERE email = $1  -- (with userInput as the $1 parameter)

XSS prevention: encode all user-generated content rendered in HTML. Use Content Security Policy (CSP) headers. React and most modern frameworks auto-encode; be cautious with dangerouslySetInnerHTML.

Authentication and Session Management: use established libraries. HTTPS everywhere. HttpOnly cookies (prevent JavaScript access). Secure flag (HTTPS only). SameSite=Lax (CSRF protection). Short expiry for sensitive tokens.

Secrets management: never hardcode secrets. Never commit secrets to version control. Use environment variables (with a secret store for production). Rotate secrets. Audit secret access.

Defense in Depth

No single security control is sufficient. Defense in depth layers controls:

• Network layer: firewall rules, VPC, WAF
• Application layer: authentication, authorization, input validation
• Data layer: encryption at rest, column-level encryption for sensitive data, row-level security
• Infrastructure: minimal IAM permissions, immutable infrastructure, audit logs

When one layer fails, others limit the damage.

Shift Left Security

"Shift left" means integrating security earlier in the development lifecycle:

• Design: threat modeling
• Code: static analysis (SAST — Static Application Security Testing), secure coding guidelines
• Build: dependency scanning (SCA — Software Composition Analysis), secret scanning
• Test: dynamic analysis (DAST), penetration testing
• Deploy: infrastructure security scanning, runtime protection (RASP)

The cost of fixing a vulnerability found during design is 1x. Found during implementation: 10x. Found in production: 100x.