Perhaps you think coding is all about sitting down with a good editing tool, maybe a web server, and banging away on your computer? Coding is much more than slinging code. To do it right, coding requires both improvisation and planning. How to write secure code is one of the first things to plan.

Writing secure code is an essential skill for any programmer. This article provides a high level overview of what secure code means in the real world. However, there are many books, web sites, people, and classes all coders should learn from as they work. How to write secure code is an ongoing skill and task.

Here are a few common steps coders can take to write secure software:

Don't Trust User Data

Roughly half of all insecure code comes from software that trusts data users put into the system, for example, while filling out a form. Every field on a form should have at least a simple check done to validate the data is in the expected format. For example, an address field should be checked it does not include a colon (:) or backslash (\); this prevents users from entering URLs to hijack your software. If you do not know how to do this, there are many code examples online for every language, as well as forums to ask for help.

In addition, when errors are returned, the message should be brief. "File not found" or "Please enter a correct address" is better than highlighting the field with the incorrect data or doing nothing at all. You want to help people who use your software without giving hackers help figuring out what worked and did not work. Be discrete when telling users what did not work and what is needed.

You Own Your Code

Code you create is your responsibility. No matter how many different ways you make your code secure, it is still your responsibility. Even if 100% security is impossible. However, coders can ensure all the minimum steps have been taken to secure code. This includes checking input data, seeking out people and other resources to learn more about how to code securely, and perhaps testing your code with malicious code to see what happens.

Model Threats to Your Code

Another step you can take is to list all the useful details about the software you're building. What are all the entry points into your code, for example, forms? Who are the users and how much do you trust them? For every function or object in your code, how are they called? Trace data from every entry point through your code to ensure the data is handled properly and has access only to the code it needs.

These details, and more, can help identify where to focus your efforts at securing your code. And don't assume a form used only by administrators should have light security. Ideally, you want to secure every form, regardless of who uses it, with special attention to forms used by people not affiliated with your company or software.

Threat models also should be looked at frequently to ensure they're up to date, account for changes to the code, and other factors that might affect the security of your code and system.

Write Your Code Securely

Perhaps the most important step to writing secure code is to build security in before you code. Define the permissions required for the application, as well as how permissions will affect every part of the software. What are the levels of users and their permissions? What data does each level of permission work with? What tasks does each level need to accomplish with the system? The answers allow the coder to design a permissions process that is tight but secure, as well as how to handle data securely as the application is coded and tested.

As you write code, it is important to not use language functions that are known to be insecure. Don't use MD5 for encryption, for example. Use something stronger. If your code already performs a task you need in another part of the code, better to harden the existing task code and reuse it than maintain two chunks of code you may or may not evaluate for security.

Another useful part of writing secure code is to create a simple repeatable process for writing code. All coding shops have clearly defined processes to write code, evaluate code, check code in to a repository, and release code. Individual programmers should set up the same gated process, if they have not already.

Other ideas for writing secure code include using configuration parameters in one or more separate files instead of hard-coding values like URLs, file paths, and other commonly used values in your code. It also helps to comment your code carefully, to help you and possibly others maintain your code.

Pick Great Tools

One important tool for coding securely is a good code analysis tool. These tools run through your code and flag issues for you to consider and fix. They also can be trained to look for specific things. And they're updated over time with new ways to evaluate code.

While you might think all this extra work kills the joy of coding, in truth it makes coding more interesting over time. Software programming is a wonderfully complex, multi-level activity. How to write secure code is simply one part of the puzzle you’ll learn as you learn programming.

Learn More

These articles provide a high level description of ways to secure code. Security is a moving target, however. The best way to keep up is to participate in the community around whatever programming language you use.

Eight Simple Rules for Developing More Secure Code

http://msdn.microsoft.com/en-us/magazine/cc163518.aspx

Writing Secure Code

http://www.cprogramming.com/tutorial/secure.html

How to Write Insecure Code

https://www.owasp.org/index.php/How_to_write_insecure_code

The Tokeneer Project

http://www.adacore.com/sparkpro/tokeneer

Fuzz Testing

https://en.wikipedia.org/wiki/Fuzz_testing

Source Code Analysis Tools

https://www.owasp.org/index.php/Source_Code_Analysis_Tools
http://en.wikipedia.org/wiki/List_of_tools_for_static_code_analysis

Joel on Software: 12 Steps to Better Code

http://www.joelonsoftware.com/articles/fog0000000043.html

OWASP Top 10 Web Application Security Risks for ASP.NET

http://pluralsight.com/training/Courses/TableOfContents/owasp-top10-aspdotnet-application-security-risks

C is for cookie, H is for hacker — understanding HTTP only and Secure cookies

http://www.troyhunt.com/2013/03/c-is-for-cookie-h-is-for-hacker.html

5 ways to implement HTTPS in an insufficient manner (and leak sensitive data)

http://www.troyhunt.com/2013/04/5-ways-to-implement-https-in.html

The Open Web Application Security Project (OWASP)

https://www.owasp.org/index.php/Main_Page
https://www.owasp.org/index.php/Top_10_2013-Top_10