How to do Secure Coding: 5 Best Practices You Should Never Forget

Secure coding is one of those things that's seen as a virtue by everyone, but practiced by (almost) no one. Plenty of excuses get in the way: "it's too time-consuming", or "developers know secure code are expensive", or even "Why bother? We'll just fix it in the next sprint."

Sound familiar?

‍

If it does, you should be worried. Security is one of those things you should never compromise on, especially when cybersecurity threats are going up by 200% every year.

Okay, enough doom and gloom. Let's get into the details of why secure coding is so important, and how your team can do it, too.

‍

Advantages of Secure Coding

It should be obvious to you that secure anything is better than the opposite. But secure coding specifically can help you and your team speed up development, reduce delays, and build a better product.

‍

Waste less time fixing security bugs

When you write secure code, you're automatically eliminating a huge set of common and extremely dangerous vulnerabilities. Fewer bugs in the build means you waste less time scrambling to fix them before the release deadline.

‍

Get fewer false positives

One of the key problems with automating security scans is that it produces a ton of false positives. These results need to be correlated before they can be turned into bug reports for the developers.

With secure code, you dramatically reduce the number of false positives that could potentially crop up in your security scan results.

‍

Deploy software in a secure state

This is—rather unsurprisingly—the biggest benefit of secure coding. When you build something that's secure by default, you can rest easy knowing that after all the secure code reviews, the SCA scans, etc., you're shipping a solid, secure product to customers.

‍

Learn how to automate SAST scans and secure code reviews in this exclusive course.

‍

5 best practices for secure coding

‍

1. Always validate user input

This is high priority. Ever heard of SQL injection? Of course you have. It's been in the top 5 most common vulnerabilities for 20 years.

Not validating user input is an easy way to fall victim to an injection attack, among other major vulnerabilities.

There are two types of input validation — allowlisting and blocklisting:

Allowlisting is the practice of only allowing the type of input that's known to be good/safe. As long as the input follows a specific format or data type, it's allowed.
Blocklisting is when you only reject the type of input that's known to be bad. Only if the user input contains a character from a blocked list of characters will the input be rejected.

‍

Of the two, Allowlisting is the more secure method of validating input. It only allows the user to enter data that's considered safe, which drastically restricts the scope of what an attacker could try to do.

For more info, check out the OWASP Cheat Sheet on Input Validation.

‍

2. Watch out for insecure components/dependencies

Supply chain attacks are currently the #1 cause of multi-billion dollar breaches every year. SolarWinds, Colonial Pipeline, and other high-profiles attacks are on that list.

The average application today relies on more than 500 open source dependencies or components. Who's keeping track of all that?

You don't want to have another Log4j on your hands, do you?

‍

Start by performing source composition analysis (SCA) scans on your apps. You can use the scan results to build a comprehensive Software Bill of Materials (SBOM). This will help you identify and remediate serious supply chain vulnerabilities in your software.

In fact, if your organisation is working with the US Government, you're required to secure your software supply chain, like, yesterday!

‍

Learn how to automate SCA scans and generate an SBOM with our hands-on course.

‍

3. Follow the Principle of Least Privilege

It's always a bad idea to provide the user with more permissions than the bare minimum they absolutely require.

Privilege can be easily abused. If a user gets more access to resources than they need, they could potentially escalate their privileges to access or even take control of your systems.

‍

The Principle of Least Privilege applies to all users, including the ones on your team. Even if your team members is trusted, an attacker could get access to their account and wreak havoc in your environment.

So remember: Give users the least privileges they need to complete a task, for the least amount of time possible.

‍

4. Securely encrypt, store, and retrieve secrets

By far the most sensitive data in your app (that all your attackers will want) are secrets: user data, passwords, access keys, etc.

You should aim to secure data whether it's at rest, in transit, or in use. Encryption plays a key role in this (geddit?).

‍

Here are some best practices for secrets management:

Use temporary credentials to manage access to your resources.
Encrypt your secrets using a Key Management Service (KMS).
Use protocols like HTTPS, API gateways, and firewalls to protect data in transit.

‍

There's a lot more you can learn about secrets management! Try out this course now.

‍

5. Use session management for authentication and access control

Attackers easily get access to web apps that don't properly secure their authentication and access control measures.

To make yours more effective, carefully manage your sessions to limit what kind of requests a user can make to the server.

Here are some helpful session management tips:

Give sessions as short a time limit as possible. If the user is inactive for too long, boot 'em.
Generate long, unpredictable session tokens that can't be 'guessed'.
Generate a new session identifier when a user re-authenticates or opens a new browser session.

‍

Learn secure coding hands-on

Train your team of developers in secure coding with AppSecEngineer's Playgrounds.

These are hands-on, sandbox-style exercises where you can learn secure coding practices in real-world environments.

The best part? They're language-specific. We've got Playgrounds in:

And there's more on the way! Find the right AppSecEngineer plan for you and start training today.

Source for article

Aneesh Bhargav

Aneesh Bhargav is the Head of Content Strategy at AppSecEngineer. He has experience in creating long-form written content, copywriting, producing Youtube videos and promotional content. Aneesh has experience working in Application Security industry both as a writer and a marketer, and has hosted booths at globally recognized conferences like Black Hat. He has also assisted the lead trainer at a sold-out DevSecOps training at Black Hat. An avid reader and learner, Aneesh spends much of his time learning not just about the security industry, but the global economy, which directly informs his content strategy at AppSecEngineer. When he's not creating AppSec-related content, he's probably playing video games.