Secure Coding Practices

Applications shall be designed using secure-by-design principles to reduce the likelihood and impact of security vulnerabilities. Development teams should incorporate security requirements during architecture and design activities rather than relying solely on security controls added during implementation.

Secure design practices include:

• Least privilege
• Separation of duties
• Defense in depth
• Fail-secure defaults
• Zero Trust principles
• Minimize attack surface
• Secure-by-default configurations
• Threat modeling during design

References: OWASP Secure by Design Principles; OWASP Threat Modeling Cheat Sheet.

Input validation is one of the most fundamental aspects of secure coding. Applications should never blindly trust data received from users, external systems, APIs, or databases. All input must be validated to ensure it conforms to expected formats, data types, lengths, and values. Proper validation helps prevent common attacks such as SQL injection, command injection, cross-site scripting (XSS), and buffer overflows. Developers should employ allow-list validation whenever possible, accepting only known-good input rather than attempting to block malicious content through deny-lists.

Reference: Input Validation - OWASP Cheat Sheet Series.

Output encoding ensures that data displayed in web pages, APIs, or applications is interpreted as data rather than executable code. Proper encoding techniques help prevent cross-site scripting (XSS) attacks by converting special characters into their safe representations before rendering them in a browser or other client application. Encoding should be applied based on the context where the data is displayed, such as HTML, JavaScript, URL parameters, or database queries.

Reference: Cross Site Scripting Prevention - OWASP Cheat Sheet Series.

Authentication verifies the identity of users, systems, or services attempting to access an application. Secure coding practices require strong authentication mechanisms that reduce the likelihood of unauthorized access. Applications should support multi-factor authentication (MFA), which combines something the user knows, such as a password, with something they have, such as a mobile device or biometric data (facial recognition). Authentication processes should use secure protocols and avoid transmitting credentials in plaintext.

Reference: Authentication - OWASP Cheat Sheet Series.

Authentication determines who a user is, while authorization determines what that user is allowed to do. After successful authentication, applications must verify permissions before granting access to resources or functions. Every request should undergo authorization checks to ensure users can only access information and capabilities appropriate to their role. Failure to enforce authorization properly can result in privilege escalation, unauthorized data access, and regulatory violations.

Reference: Authorization - OWASP Cheat Sheet Series.

Applications should enforce a minimum password length of at least 12 characters, permit long passphrases, screen passwords against known compromised password lists, and avoid arbitrary composition requirements that encourage predictable user behavior.

Passwords must never be stored in plaintext; instead, they should be protected using strong one-way hashing algorithms such as Argon2, bcrypt, or PBKDF2, combined with unique salts. Secure password reset mechanisms should be implemented to prevent account takeover attacks and user enumeration.

Reference: Password Storage - OWASP Cheat Sheet Series.

Session management is critical for maintaining authenticated user interactions. Applications should generate strong, unpredictable session identifiers and transmit them only over encrypted channels such as HTTPS. Session tokens should be invalidated upon logout, timeout, or credential changes. Developers should implement secure cookie settings, including HttpOnly, Secure, and SameSite attributes, to reduce the risk of session hijacking and cross-site request forgery (CSRF) attacks.

Reference: Session Management - OWASP Cheat Sheet Series.

Cryptography is essential for protecting sensitive data from unauthorized disclosure and tampering. Secure coding practices require the use of established, industry-approved cryptographic algorithms and libraries rather than custom implementations. Data should be encrypted both in transit and at rest using strong encryption standards such as TLS and AES. Proper key management is equally important, as even the strongest encryption can be compromised through poor key handling practices.

Reference: Cryptographic Storage - OWASP Cheat Sheet Series.

Error handling should provide meaningful feedback for developers and system administrators without exposing sensitive information to users or attackers. Detailed system errors, stack traces, database messages, and configuration information should never be displayed publicly. Instead, applications should return generic error messages while securely logging detailed information for troubleshooting purposes. Effective error handling reduces information leakage that attackers could use to exploit vulnerabilities.

Reference: Error Handling - OWASP Cheat Sheet Series.

Protecting sensitive data is a core objective of secure coding. Applications should identify and classify data according to its sensitivity and apply appropriate safeguards. Sensitive information such as personal data, financial records, health information, and credentials should be encrypted, access-controlled, and retained only as long as necessary. Data minimization principles help reduce exposure by collecting and storing only the information required for business operations. Compliance with regulations such as GDPR, HIPAA, or FERPA may also influence data protection requirements.

Reference: User Privacy Protection - OWASP Cheat Sheet Series.

Modern software development relies heavily on third-party libraries, frameworks, APIs, and open-source components. While these components accelerate development, they can introduce vulnerabilities if not properly managed. Organizations should maintain an inventory of all third-party dependencies, monitor them for security advisories, and promptly apply updates or patches. Developers should obtain components from trusted sources and regularly scan dependencies for known vulnerabilities using automated security tools.

Reference: Vulnerable Dependency Management - OWASP Cheat Sheet Series.

Applications shall not store passwords, API keys, encryption keys, connection strings, certificates, or authentication tokens in source code repositories, configuration files, scripts, or application packages.

Sensitive secrets shall be:

• Stored in approved secrets management solutions.
• Rotated periodically.
• Access-controlled using the principle of least privilege.
• Logged and monitored for unauthorized access.

Applications exposing APIs shall:

• Authenticate API consumers.
• Implement authorization checks for every request.
• Validate all input parameters.
• Use secure transport protocols.
• Implement rate limiting and abuse protection.
• Protect against injection and mass assignment attacks.

Applications shall generate audit records sufficient to support monitoring, investigation, incident response, and accountability.

Security-relevant events should include:

• Authentication attempts
• Authorization failures
• Privileged actions
• Administrative changes
• Account provisioning and deprovisioning
• Security configuration changes
• Data export activities
• Application errors affecting security controls

Applications shall avoid logging:

• Passwords
• Authentication tokens
• Encryption keys
• Sensitive personal information unless specifically authorized

Error messages presented to users shall be generic and shall not disclose system configuration details, software versions, stack traces, file paths, database schemas, or other information that could assist an attacker. Detailed diagnostic information should be recorded in protected application logs accessible only to authorized administrators.

Development teams shall maintain an inventory of third-party components and dependencies used within applications.

Where supported:

• Software Bills of Materials (SBOMs) should be generated and maintained.
• Dependencies should be scanned for vulnerabilities throughout development and prior to deployment.
• Components with known exploitable vulnerabilities shall be remediated, replaced, or formally risk accepted.

Applications shall undergo secure code review prior to production deployment.

Code reviews should:

• Verify compliance with secure coding requirements.
• Identify common vulnerability classes.
• Validate security controls implemented during development.
• Verify that hardcoded credentials and secrets are absent.

Both peer review and automated analysis tools should be used whenever feasible.

Applications shall undergo security testing appropriate to the risk and complexity of the application.

Testing may include:

• Static Application Security Testing (SAST)
• Dynamic Application Security Testing (DAST)
• Software Composition Analysis (SCA)
• Interactive Application Security Testing (IAST)
• Penetration testing
• Manual security assessments

Identified vulnerabilities shall be tracked and remediated according to organizational vulnerability management requirements.