Building Better Security (4): Secure Coding Standards

SDLC flow diagram with implementation highlighted

I've been sharing ideas on how to build security into your development process. If you missed any of the previous articles, here are the links:

This week I want to discuss coding standards.

Coding standards matter

Yes, you have coding standards. But do you follow them rigorously?

In many organisations, coding standards are often ignored. Sometimes there are reasons for this. The standards may be out-dated, inconsistent, or vague. Or they might focus too much on aesthetics (where to put the curly braces) instead of techniques.

Good coding standards can improve code quality and reduce the cost of maintenance. Joel on Software provides a good explanation of what a coding standard should do:

“Look for coding conventions that make wrong code look wrong.”

What are secure coding standards?

Secure coding standards add security guidelines to your coding standards. They help developers write code that minimizes security vulnerabilities.

We know that there are many ways to code any development task. Some solutions are more secure than others. Secure coding standards make sure that developers take the most secure approach. Standards can help to prevent, detect and eliminate code that may compromise your system.

Components of a secure coding standard

Last week I discussed design guidelines like defence in depth and least privilege. These principles must be covered in your coding standards.

Here are a few key coding practices to include in your standards:

Authenticate and secure credentials

Specify how credentials must be handled. Don't leave it up to the individual developer to decide what is appropriate. And don't rely on the default settings in any third-party software you are using.

I wrote about this before, in "What did you do with my password?"

Validate input and sanitize output

You must validate input from all untrusted data sources. Proper input validation plays a big role in reducing the number of vulnerabilities. Validate data from users, command-line arguments, databases, file streams and every untrusted source.

Don't just check the data against the business rules. Check for potentially hazardous characters and character sets. And make sure that all validation failures result in input rejection.

Sanitize, and if necessary encode, the data that you pass to other systems. Attackers may be able to use vulnerabilities in those components.

I wrote about this in "How clean is your data?".

Manage sessions and control access

Once the user or system has been authenticated, make sure the session is carefully managed. Do not allow persistent or concurrent logins. Make sure that logout functionality terminates the session properly. Set timeouts that are as short as possible.

Restrict access to only authorized users. Deny all access if the application cannot access security configuration information.

Pay attention to compiler warnings

I hope you do actually read the error messages and warnings from your compiler. Most compilers have options that allow you to specify the level of warning. So, for example, you can set this to only show compile errors, or to show all possible warnings.

You should compile code using the highest warning level available. But don't just ignore the warnings: make sure that your code compiles without any warnings.

Handle errors and logs securely

Make sure that error responses do not disclose any sensitive information. Be careful of default error messages that reveal the system that is being used.

Make sure you log all relevant events, but don't store sensitive information in logs. And restrict access to logs to authorized individuals.

I wrote about this in "Beware the error message".

Configure systems securely

Make sure all patches have been applied to your systems. Remove all unnecessary or unused functionality and files.

Pay attention to the headers and HTTP methods you are using. Make sure you are using encryption for the transmission of sensitive information.

Use a static code analyzer

Static code analysers are tools that analyse your code without running it. Lewis wrote an article about Java static analyzers on our blog. He describes them as “a peer reviewer on steroids, where the reviewer is extremely knowledgable about the language and APIs, brilliant at identifying small problems, never misses a thing and stays focused during the entire review. And does it over and over consistently without getting irritated, tired or frustrated.”

Static Application Security Testing (SAST) is the use of a static code analyzer that is designed to flag security violations. This is also known as "white-box testing". I'll talk about in more detail in a future email.

Useful reference

Use the OWASP Secure Coding Guildeines (PDF) as the starting point. Then write your own secure coding guidelines from there.

Have you got secure coding standards in place? Are you using them? Please share your views and comments.

Join me next week for Building Better Security - Part 5: SAST.

Leave a Comment

Your email address will not be published. Required fields are marked *

Thank You

We're Excited!

Thank you for completing the form. We're excited that you have chosen to contact us about training. We will process the information as soon as we can, and we will do our best to contact you within 1 working day. (Please note that our offices are closed over weekends and public holidays.)

Don't Worry

Our privacy policy ensures your data is safe: Incus Data does not sell or otherwise distribute email addresses. We will not divulge your personal information to anyone unless specifically authorised by you.

If you need any further information, please contact us on tel: (27) 12-666-2020 or email info@incusdata.com

How can we help you?

Let us contact you about your training requirements. Just fill in a few details, and we’ll get right back to you.