Secure Development Principles

🎯

Learning Objectives

["Understand security by design.","Understand secure defaults and least privilege.","Apply input validation and output encoding.","Understand secure authentication and authorization.","Protect sensitive data.","Understand dependency and patch management.","Apply secure error handling and logging.","Understand threat modeling.","Understand code review and security testing.","Apply secure deployment and maintenance practices."]

📖

Lesson Content

Secure software development means considering security throughout the entire
development lifecycle rather than waiting until an application is completed
before looking for vulnerabilities.

1. Security by Design

Security by design means considering security requirements during planning,
architecture and implementation.

Developers should ask security questions before writing code:

What information is sensitive?
Who should access it?
What could go wrong?
What happens if an input is malicious?
What happens if a dependency becomes vulnerable?

2. Least Privilege

The principle of least privilege means giving users, applications and services
only the permissions they actually need.

Excessive privileges increase the impact of compromised accounts and software.

3. Secure Defaults

Applications should be secure when first deployed. Users should not have to
discover hidden security settings before basic protections become active.

4. Defence in Depth

Use multiple independent security controls. If one control fails, additional
controls should still provide protection.

5. Input Validation

All untrusted input should be treated as potentially dangerous.

Validation should be based on what the application expects rather than simply
trying to remove a few known malicious characters.

6. Output Encoding

Data that is safe in one context may be dangerous in another. Output should be
encoded according to its destination, such as HTML, JavaScript, URL or SQL.

7. Parameterized Queries

Applications should use parameterized database queries instead of constructing
SQL statements from untrusted strings.

8. Authentication

Authentication controls who a user is.

Secure authentication includes strong password handling, secure sessions,
MFA where appropriate and protected account recovery.

9. Authorization

Authorization determines what an authenticated user is allowed to do.

Every sensitive server-side action should verify authorization.

10. Secure Password Handling

Passwords should never be stored in plaintext. Applications should use trusted
password hashing APIs and secure authentication flows.

11. Sensitive Data Protection

Sensitive information should be identified and protected in databases, backups,
logs, network traffic and application responses.

12. Secrets Management

API keys, database passwords, private keys and application secrets should not
be hard-coded into public source code.

Use appropriate environment configuration or dedicated secret-management
systems.

13. Dependency Management

Applications rely on frameworks, libraries, plugins and packages. Developers
should maintain an inventory of dependencies and monitor them for security
updates.

14. Secure Error Handling

Error messages should help legitimate users without exposing sensitive internal
information.

Production responses should not reveal database credentials, stack traces,
internal paths or implementation secrets.

15. Logging and Monitoring

Security-relevant events should be logged appropriately.

Logs should not contain passwords, session tokens or other secrets.

16. Threat Modeling

Threat modeling is a structured way to identify what can go wrong with an
application and determine appropriate mitigations.

Developers can identify assets, trust boundaries, entry points, attackers and
potential abuse cases.

17. Code Review

Code review should consider both functionality and security.

Reviewers should look for authentication weaknesses, authorization errors,
unsafe input handling, sensitive-data exposure and insecure dependencies.

18. Security Testing

Security testing can include:

Static analysis.
Dependency scanning.
Dynamic testing.
Manual review.
Configuration review.
Authorized penetration testing.

19. Secure Configuration

Development and production environments should use appropriate security
settings.

Debugging features should not expose sensitive information in production.
Unnecessary services and interfaces should be disabled.

20. Secure Deployment

Deployment processes should protect source code, credentials, infrastructure
and configuration.

Only authorized personnel and automated systems should be able to deploy
production software.

21. Patch Management

Security does not end when an application is deployed. Vulnerabilities are
discovered over time, so systems and dependencies must be updated.

22. Backup Security

Backups may contain the same sensitive information as production systems.
They should therefore be protected using appropriate access controls,
encryption and retention policies.

23. Secure SDLC

A secure software development lifecycle integrates security into:

Planning.
Requirements.
Architecture.
Development.
Code review.
Testing.
Deployment.
Monitoring.
Maintenance.

24. Practical Secure Development Workflow

Identify assets and security requirements.
Model threats.
Design secure controls.
Implement secure code.
Review the code.
Scan dependencies.
Test security controls.
Deploy securely.
Monitor the application.
Patch and improve continuously.

25. Practical Authorized Lab

Choose a small local PHP application and create a security review checklist.
Identify its authentication, authorization, input validation, output encoding,
database access, logging, dependency and deployment controls.

Document each security weakness you identify and propose a defensive
improvement.

26. Common Secure Development Mistakes

Security added only after development.
Trusting client-side validation.
Using excessive permissions.
Hard-coding secrets.
Ignoring dependency updates.
Exposing production debug information.
Failing to review authorization logic.
Logging sensitive information.
Ignoring security requirements during architecture.
Failing to maintain deployed applications.

27. Knowledge Check

What is security by design?
What does least privilege mean?
Why are secure defaults important?
Why should input be treated as untrusted?
Why is authorization different from authentication?
What is threat modeling?
Why should dependencies be monitored?
Why should secrets not be hard-coded?
What is defence in depth?
Why is security maintenance necessary after deployment?

28. Summary

Secure development is a continuous process. Developers should build security
into requirements, architecture, code, testing, deployment and maintenance.

The safest application is not the application that was tested once. It is the
application that continues to be designed, reviewed, monitored and improved
with security in mind.

💻

Code Example

<?php

$stmt = $pdo->prepare(
	'SELECT id, username FROM users WHERE username = :username'
);

$stmt->execute(
	array(
		':username' => $username,
	)
);

$user = $stmt->fetch(PDO::FETCH_ASSOC);

if ( $user ) {
	// Continue with secure authentication and authorization checks.
}

⭐

Key Takeaways

["Build security into the entire software lifecycle.","Use least privilege.","Use secure defaults.","Validate untrusted input.","Encode output for the correct context.","Use parameterized database queries.","Separate authentication from authorization.","Protect sensitive data and application secrets.","Keep dependencies updated.","Use threat modeling, code review and security testing.","Protect production configuration and deployment.","Continue monitoring and maintaining applications after release."]

Learning Objectives

Lesson Content