Six tips for Creating Secure Code

Home / Coding / Six tips for Creating Secure Code

Whenever you’re developing an application one of the most important things you need to do from a security point of view is making sure that it is coded correctly. If you fail to do this your application will have several security vulnerabilities and trying to go back and fix it months or years later will be much more difficult. It’s best to build the application with all of the security features in mind, while the code is still fresh in your head. However, many developers don’t know what the best way to write secure code is and that’s why I made this article. This is a list of six tips for writing secure code for your software application.

1) Don’t hard-code login credentials

One common but easily fixed mistake is hard coding login credentials. When you do this, worst case scenario you essential give the hackers your login credentials. Any sensitive information should never be hard coded in your code. 

2) User Authentication

A common attack by hackers is too try and brute force a user’s password. To do this requires them to try random combinations of characters hoping to get a match or in the case of a dictionary attack they use a list of commonly used passwords. To prevent against this your applications should always have some type of account lockout functionality as well as enforce that passwords meet a strength criteria. A strong password usually consists of 12-16 characters, capital and lowercase letters, numbers, and special characters. You should also build in 2FA as an option for logging in.

3) Randomize your session IDs

It’s important that you make your session ID tokens unpredictable, if you fail to do so they can used by hackers to access other people’s accounts. It’s not sufficient to change one variable such as the uid number since this can be easily brute forced. 

4) Don’t trust user input

A significant amount of vulnerabilities in web applications including cross site scripting, SQL injections and buffer overflows can be attributed to the fact that the software trusted user input. Every field on an input form should have at least one check to validate that the data is in the correct format. For example, an address should be checked to make sure it doesn’t include a colon or backslash. 

5) Limit what your error codes say

When returning an error code you want to keep it as discrete as possible. You want to let users know what needs to be corrected without giving hackers any hints about what part of their attacks are working. Also, you don’t want to reveal anything about the inner workings of your application. Some simple examples of discrete error messages would be “error: File not found”. It should not contain things like software versions or file directories, that would be returning too much information.

6) Use automated tools

Fuzzers for example are a good way to test that your application is built to properly handle crazy user inputs. Fuzzing is the process of providing invalid, unexpected or random data as inputs into your software. This way you can see how well your application handles it and if it leads to any security issues. Also, there are tools like Static application security testing (SAST) and dynamic application security testing (DAST), that can scan your code and test it at runtime for security issues. If you’re interested in either one of these Veracode may be a company you want to look into. 


Creating secure code is the most important aspect of securing a web application. Flaws in the design of the code is what makes most web applications vulnerable to common injection-based attacks. Since coding is not a specialty of mine, I keep this to a pretty high level of explanation. If you want some more details on how you can implement these concepts in the applications that you design, here are some good places to start:

How to write secure code?. Protect yourself against Broken Auth &… | by Aditya Anand | InfoSec Write-ups (infosecwriteups.com)

How to Write Secure Code | beanz Magazine | (kidscodecs.com)