Secure Coding Practices

Building secure applications starts with writing secure code. As a developer, understanding and applying the 14 practices below helps you protect your software from vulnerabilities that attackers could exploit.

What Are Secure Coding Practices?

Secure coding practices are guidelines that developers follow to build secure, stable, and reliable software. These practices help protect software from malicious attacks, while also giving a framework to ensure the expected and secure behavior of applications.

Integrating secure coding practices from the start of the software development life cycle (SDLC) allows programmers to reduce risks and improve the overall user experience.

While specifics can vary between teams and projects, organizations like the Open Worldwide Application Security Project (OWASP) provide widely accepted frameworks and resources that guide developers. 

Why Is Secure Code Important?

With the ongoing rise of cyberattacks, very small vulnerabilities in programs can lead to devastating consequences. This is why cybersecurity professionals and security-minded developers internalize the phrase, "Defenders need to be right every time. Attackers only need to be right once."

Even historically, people with malicious intent have always taken full advantage of software malpractices, like the Phrack TCP hack.

More recently, Bangladesh's Birth and Death Registration Office experienced a data leak in 2023, which exposed millions of citizens' personal information, showing how insecure systems can have cascading consequences.

Vulnerabilities like these cause financial and reputational damage for organizations while also potentially putting end-users at risk beyond your platform.

The need for secure coding practices has become even more prevalent in recent years as companies embrace AI-assisted programming. Developers need to be more vigilant of holes in their programs because of the vulnerabilities AI-generated code can naturally produce.

14 Secure Coding Practices All Teams Should Implement

Following these practices greatly reduces the risk of becoming a victim of a cyber attack and minimizes the impact if you do.

OWASP created a list of security-minded practices that cover every digital inch of your codebase and infrastructure.

The following is our take on OWASP's secure coding practices, providing the most important practices with real-world examples of what can go wrong if you don't implement them.

Input Validation

Unexpected inputs are one of the most avoidable problems prevalent in development. Input validation checks that the inputs entering your system are exactly what you expect.

It works by only allowing expected ranges or formats to pass through, which helps you avoid SQL injections, cross-site scripting (XSS), buffer overflows, and other attacks.

As a basic example, if your social media platform expects a user's age, the input should only allow positive integers with a reasonable age, like 0-120. Neglecting validation can lead to attackers entering SQL queries instead of their age, leaving the door open for them to compromise your application.

In 2012, LinkedIn was hit by what was most likely an SQL injection for failing to follow this practice, exposing millions of passwords.

You can enhance your validation by using allowlists instead of blocklists, as it ensures only safe data reaches the rest of your system.

Libraries and frameworks often provide built-in validation functions that simplify this process, making it a no-brainer to have input validation as a part of every development workflow.

Output Encoding

Output encoding allows data sent from the server to the client to be safely interpreted by the client-side application. This makes it hard for malicious code (like scripts or HTML injections) to execute on the user's end, which is a common cause of cross-site scripting attacks.

By encoding all outputs on the server, developers ensure that any malicious injections will be treated as plain text instead of executable code.

For example, imagine a blog platform where users can post comments. Without proper encoding, an attacker could post and trigger a pop-up or inject scripts for every site visitor. Encoding these outputs would render these tags harmless, displaying them as plain text instead.

Always use a standardized and tested encoding method throughout your application. Libraries and frameworks like React and Angular handle much of this automatically, but in custom server-side environments, developers often use dedicated libraries, such as OWASP's Java Encoder or ESAPI.

Encoding should also cater to your application's specific character sets (such as UTF-8) to prevent misinterpretations and to make certain that security is applied uniformly across all layers of your system.

Authentication and Password Management

Every page not built for public use should include strong authentication, since weak authentication is the first entry point for credential-based attacks.

Let's look at an example of an e-commerce company with an internal dashboard containing customer data. If the authentication for this page is not particularly robust, a skilled attacker would only need the link to get in and expose this sensitive information.

Here are some practices to implement to help with authentication and password management:

• Strong credential requirements: Requiring a combination of upper- and lower-case characters, numerals, and special characters.

• Multi-factor authentication (MFA): Verifying users with more than one source, such as a password and a confirmation email or text.

• Hashing: Encrypting passwords using modern algorithms, such as bcrypt or Argon2.

• Rate limiting/CAPTCHA: Securing authentication endpoints against brute-force, automated attacks.

Session Management

Session management allows user sessions to be uniquely identified, securely managed, and properly expired. Applications should only recognize tokens either from the server or trusted frameworks to prevent attackers from hijacking or forging sessions.

In a finance app, if session tokens aren't securely managed, an attacker could predict or steal session IDs to gain access to accounts and their money. Using secure, randomly generated tokens (often generated with frameworks like Express, Django, or Spring) significantly reduces this risk.

Robust session management is equally non-negotiable for real-time applications, like multiplayer games or messaging platforms. For instance, if a WebSocket server doesn't validate origin headers at the start of a connection, hackers can hijack existing sessions and impersonate another user.

To prevent interception, it's important to only send session IDs over HTTPS while also setting flags like HttpOnly and Secure on cookies. Other best practices include token expirations and regenerating tokens on privilege changes, such as logging in.

Access Control

Giving users access to the data, resources, and actions that align with their authorization level greatly improves application security.

If you're building a dating app, at a standard user-level, you might control for visibility of names, locations, and photos; paid users might have access to additional features, like seeing who liked them or viewed their profile; internal team members, like moderators and support staff, would have access to additional features and data that pertains to their respective roles.

Secure software should rely on a single, centralized component to manage permissions. This reduces complexity and minimizes the risk of inconsistencies across different horizontal and vertical segments of your application. Scattering access checks throughout your program makes it easier for attackers to exploit.

Here are some of the best practices for implementing access control:

• Principle of least privilege: Users and staff should have the bare minimum permissions to perform their actions.

• Role/attribute-based access control: Allows for easier allocation of permissions while also helping with auditing.

• Access logs: Record who viewed what and when.

• Server-side validation: Permission validation on the client's end can easily be bypassed.

Centralized and well-tested access control reduces the damage an attacker can do, even if they compromise an account.

Cryptography

Encryption, decryption, key generation, and hashing are all cornerstones of cybersecurity. As with access control, cryptographic functions should never be performed on the client side, where they can be intercepted or tampered with.

As mentioned earlier, when storing user passwords, developers have to make sure that they are hashed with strong algorithms, such as bcrypt, scrypt, or Argon2, all with proper salting. You must avoid weak algorithms, like MD5 or SHA1; among other issues, hackers can easily brute force them.

Similarly, protocols like TLS 1.2+ alleviate the risk of man--in--the--middle attacks by encrypting data in transmission.

Key management is also vital. Keys should be securely stored, rotated periodically, and never hardcoded in the source code or even the configuration files. Toyota learned this the hard way after realizing that one of its credentials was hardcoded and visible to the public in a GitHub repo.

Using trusted frameworks for encryption allows developers to protect data from exposure while maintaining compliance with industry standards. And while end-to-end encryption isn't part of OWASP's secure coding practices, it is recommended for safeguarding data exchanges.

Error Handling and Logging

Error handling and logging are helpful in testing out your application, but showing detailed error logs (like stack traces, database queries, or API keys) to an end user can expose sensitive information, which threat actors can exploit.

For instance, if a login page fails and displays the error message "Invalid username in database query SELECT * FROM users WHERE username='admin'," an attacker can extrapolate the name and structure of the table, which can help in crafting an SQL injection.

Instead of having detailed logs, make sure your application has user-facing generic messages like "Login failed, please try again".

Logs should be securely held in trusted servers, and access to these logs should only be given to authorized personnel. Avoid logging sensitive information such as passwords, credit cards, or session tokens.

If errors are handled gracefully and logging is done responsibly, you will have deeper security and operational insight.

Data Protection

Data is the most important asset for development teams, which is why it is crucial to protect data integrity throughout the SDLC.

The principle of least privilege also applies to data protection. You greatly reduce the risk of abuse or accidental data leaks by tightly controlling access to your data.

Similarly, temporary or cached copies of sensitive data should be secured and deleted as soon as they're no longer needed.

As mentioned earlier, encrypting stored data is also a crucial step in data protection. One of the most famous cyberattacks involved a company called RockYou, which experienced a massive leak of 30+ million accounts because it failed to encrypt its database and stored passwords in plaintext.

You must also gatekeep encryption keys internally, so only authorized team members can view them.

Communication Security

Communication security encompasses data in transit. Data transmissions should use Transport Layer Security (TLS). Applications should never fall back to insecure connections if TLS handshakes fail.

Use TLS for all authenticated pages, sensitive APIs, and external system communications involving private data. Standardize TLS implementations across the system for consistency and security, specify character encodings to prevent misinterpretations, and filter sensitive parameters from HTTP referer headers when linking to external sites.

System Configuration

You can build an application that is (practically) impenetrable to attack, but no amount of secure code can save your internal systems if you don't configure them properly.

One of the easiest ways to safeguard your system is to update and patch your:

• Operating system(s)

• Application, web, and cloud servers

• Databases

• Runtime environments

• Frameworks, libraries, and other dependencies

Updates and patches often contain security fixes for known vulnerabilities, so it's important to regularly check if any are available.

If you cannot update certain components, such as needing to work with an older version of Java in a banking application, you should still apply this practice to what you can. You can also harden your environment by running firewalls or isolating parts of your system through virtual machines or containers.

You must also follow security best practices for each component in your system. For instance, a Canadian airline failed to properly set up file permissions and stored its credentials in plaintext, which allowed hackers to easily access databases, internal mail accounts, and more. If they had strict access control and kept sensitive information somewhere safe, this wouldn't have happened.

Separating your production and development environments is another method of effective configuration management. It prevents test code and sensitive metadata from creeping into production releases and personal data from real users from being copied into test environments.

Finally, maintaining an asset management system and using change control tools to track updates can allow easier audits and consistent, secure deployments.

Database Security

Database security is the practice of protecting your database management systems from unauthorized access, leaks, and corruption.

Prevent SQL injection attacks using strongly typed, parameterized queries and following the input validation and output encoding practices. You should always reject or sanitize queries when validation fails.

As discussed earlier, privileges for both people and functions should be as restrictive as possible, like giving read-only permissions instead of full access to a reporting module.

Always store connection strings in an encrypted data store on a trusted server and never hardcode them within the program.

Other ways to reduce your attack surface include closing connections as soon as they're not needed and disabling unused accounts or vendor-provided defaults.

File Management

Preventing malicious software from entering your program requires strong file management.

Passing user-supplied data into your function calls can be very dangerous because there is no guarantee of what the data contains until it's verified, so make sure to have checks on all data. Restrict file types to those essential for operation.

If your plagiarism software accepts PDF files for checking student work, validate both the file types and the file headers because extensions are very spoofable.

External files should be stored outside the web root, with execution permissions disabled to prevent accidental or malicious execution. Automate regular malware checks, and never reveal absolute file paths to the user.

Memory Management

You can address buffer overflows, data leaks, and similar issues with secure memory management.

For example, if an application accepts usernames, limit the input length to prevent overwriting memory and crashing the system. Validate input and output sizes and truncate strings to a reasonable length before processing them.

If you know that a function has a vulnerability that occurs a partial amount of the time, don't take the risk. Use non-executable stacks when possible and explicitly release memory resources when no longer needed.

General Coding Practices

Following some other general coding practices can further reduce your attack surface, including:

• Conducting proper unit and integration testing

• Verifying any third-party integrations, libraries, and APIs for necessity and security

• Implement tamper protection and maintain file integrity with checksums or hashes

Finally, if elevated privileges are required, raise them as late as possible and drop them immediately afterwards. For example, an installer might require administrator privileges, but you should remove them once the installation completes.

Secure Coding Practices Throughout the SDLC

You should follow these practices from the Requirements and Planning stage all the way to Deployment and Maintenance to keep your app and internal systems safe.

These practices align with every stage of the SDLC, so security is integrated from planning through maintenance as follows. 

Planning and Requirements Analysis

At this stage, you should be defining your security requirements. Depending on factors like what your application will do and who will use it, you'll need to consider what authentication will look like, how you'll encrypt and store your data, and who will require access to what.

You must also assess your attack surface and perform threat modeling. What are the different parts of your application an attacker can exploit? What data will they most likely target? What attacks must you protect against?

Sticking to budgets and deadlines means you'll likely need to make tradeoffs, so you should prioritize stronger protections for the most sensitive data you work with. Additionally, if you're building a product in a regulated industry, factor in security requirements you're legally obligated to follow alongside secure coding practices.

Design

This is where you start to fill out more of the details of your security implementation. Build on the previous phase to create the roles for your role-based access control setup based on the principle of least privilege, prepare to centralize your security controls, map out how data will flow securely, make your validation whitelists, and more.

As you finalize the details, revisit them through the eyes of a threat actor. Have you left any holes in your designs? Have you followed vendor security recommendations for third-party tools? Is your internal system locked down to prevent accidental or malicious changes to infrastructure?

Implementation

Run through the secure coding practices checklist as your team starts building the application based on the designs from the previous stage. Strictly validate your inputs, encode outputs safely, and parameterize your queries.

If you're working with libraries or frameworks like Django or React, rely on the features that will simplify app security. For instance, React has a level of built-in XSS protection because the DOM escapes values in JSX, converting potential malicious scripts into strings prior to rendering.

Salt your passwords and use algorithms like bcrypt or Argon2 to hash them. Properly store them and API keys.

When you define roles, grant them the lowest amount of access possible and validate them on the backend to reduce the chance of users escalating privileges.

Perform code reviews often to find vulnerabilities, like hardcoded keys, early in development. Always review code before merging, as well. Combining manual review with automated tools gives you deeper coverage.

Testing

Instead of performing unit and integration tests with expected input, adopt negative testing and throw malformed inputs at your application to see if they're rejected or pass through, as well as to check that your errors don't reveal sensitive information.

Test how strong your access control is for each role individually, both user-facing and internal: Can your dating app's free users see who viewed their profile by poking around in the browser console? Can help desk agents log into your cloud admin panel or view sensitive customer data?

Use automated solutions for static and dynamic application security testing and check your dependencies with software composition analysis tools.

Deployment and Maintenance

Before going live with your product, be certain that your development and production environments are completely separate and check for any updates or patches to system components.

Post-launch, your responsibilities do not end. You'll need to vigilantly monitor logs for suspicious activity. Your regional telehealth app based in the US shouldn't have users logging in from another continent.

Have internal and/or external penetration testers conduct extensive testing regularly. They will put your secure coding practices to the test and provide feedback to improve any flaws they might find.

If you have internal servers, you might want to bring the pen testers onto the property to test physical security, as well; hackers might compromise your systems digitally by logging into your SSH server or physically by tailgating an unaware employee or breaking and entering. 

Next Steps

Application security is one of the most important features that users expect from the programs they use. If there is a risk of your app failing to protect their data, they'll simply pick a more secure competitor.

By implementing the secure coding practices above from the first stages of a product or project, developers can reduce the risk of client and company data compromise. Beyond OWASP's recommendations, devs can dig deeper into building safe apps by learning about API security best practices and Datagram Transport Layer Security (DTLS).