Just when you thought that the healthcare.gov debacle was finally on the uptick, a “white hat” hacker just testified on Capitol Hill that security was never properly built into the site. He claims that fixing the critical-to-high exposures could require up to a year of work.

Not exactly what you want to hear about a website that stores your most sensitive information.

I bring this up to highlight an important point: Despite the rising importance of proper security, best practices are often ignored. Basic security mistakes still plague many web applications…including healthcare.gov.

As more development shifts to the web, and more data is stored on the cloud, security is a critically important topic. A single security misstep can compromise confidential business data or your customer’s personal information.

Today, let’s get back to the basics. While web application security is a broad topic, I’d like to focus on the security mistakes that web application developers should never make. These are the “basic” security principles that should never be ignored.

So, what are these security principles? What security mistakes should you never make? To help you answer those questions, we’ve compiled advice from some experts in the field (as well as some of my own) and listed everything below. Here are 10 security mistakes you should never make when developing web applications:

1. Developing your own security methods

Some developers make the flawed assumption that a homegrown algorithm or authentication method is actually safer. After all, hackers have never seen it before, so they’ll have more trouble cracking it…right? Wrong.

“Developing your own authentication or login methods is a mistake, because you will make a mistake that hackers will discover,” says James Kelley, a Security Engineer at Kelley Consulting Company, LLC. “Instead, rely on existing libraries which have been thoroughly tested.”

Why are existing libraries more secure? Because they’re constantly tested by the security community. As such, they’re less likely to include major security holes that one person might overlook. As the famous security specialist, Bruce Schneier, likes to say: “Anyone can invent an encryption algorithm they themselves can’t break; it’s much harder to invent one that no one else can break.”

2. Accessing a database directly with user supplied information

“When developing an application, particularly a web application, many developers fail to adequately validate the input they receive from users,” says Dwayne Melancon, Chief Technology Officer at Tripwire. “This has a ‘data hygiene’ impact in that it can allow invalid data to enter your customer database, for example, but it has even greater security implications. Failure to validate input (whether from a web form or via an API) is what allows SQL injection, cross-site scripting, command injection, buffer overruns, and other common web exploits to succeed.”

This is one of the most common mistakes found in web applications. If unprotected, users can use input fields to inject malicious scripts into your application or access proprietary data from your database. Of course, most users will never attempt anything malicious, but you must approach user input with a defensive mindset.

“Do NOT trust user input, EVER,” says David Campbell, a serial entrepreneur and security expert. “Validate input client side (e.g. Javascript validation), but make sure you also validate it server side. Failing to do this is what creates serious vulnerabilities like cross site scripting and SQL injection.”

3. Focusing on components, not the overall system

With larger development projects–where multiple developers work on different parts of an application–the tendency to focus on individual components arises. Sure, each part may be secure, but…how secure are they as a whole? Remember, your application is only as strong as its weakest point.

“Many security issues happen not within components themselves, but during the ‘handoffs’ that occur as data and processes flow from one part of a business process to the next,” explains Melancon. “Developers are often charged with working on one portion of a business process and may not understand other parts of the process. This lack of visibility can allow insecure handoffs to occur, which can expose data to various attacks such as “man in the middle” attacks, data integrity problems, and information leakage.

It is vital to have a system view of your business service so you can understand how all the components work together and how they can be secured as a combined entity.”

4. Adding security at the end of development

The problem with the healthcare.gov site: security was never built in. It’s not something you can simply add on at the end. It’s a function of your entire application architecture. As I explained in this article, architecture is the most important aspect of application development because it affects all other aspects of the application…including security.

“While there are any number of symptoms of this mistake, such as misconfigurations and vulnerabilities, they all trace back to treating security like a feature that you can add at the end of development,” explains Tim Erlin, Director of IT Security and Risk Strategy at Tripwire. “’Great, all the functionality works. Now let’s secure it.’ This mentality increases risk by creating architectural security flaws. It’s incredibly hard to deal with things like Cross Site Request Forgery and the many types of SQL injection after the application is fully deployed.”

5. Letting users create weak passwords

Every time hackers breach a popular web application and expose user passwords, one thing becomes instantly clear: Users have horrible security habits. The most popular password in most every instance: 123456. As a web application developer, you can’t let users create weak passwords.

“A strong password is one that is short enough to remember, but long enough to make it difficult for others to guess,” says Steven Pickles, Co-Founder of Recourier. “Require a minimum length of at least 10 alphanumeric characters, though passwords that make sense to human brains are more likely to be longer and more effective. Keep in mind it takes eons longer to randomly guess the password ‘waterdownmobileboomeranggrease’ than it does ‘%sdJil*7m’.”

He brings up a great point. The best passwords aren’t necessarily the most complex. Forcing users to create overly complex passwords (that they’ll never remember) often leads the user into unsafe practices, like writing their password down and taping it to their computer. The best passwords are both long and memorable.

6. Storing passwords in plain text

“The most common mistake web application developers make is failing to secure user authentication credentials,” explains Pickles. “Users implicitly trust sites to get this right, but, unfortunately, too many get it wrong. By and large, the culprit is a weakness in the way passwords are handled and stored.”

The question is, how can you store user passwords correctly? While we could focus an entire article on the proper storage of user authentication credentials, today let’s highlight just one of the most common–yet insecure–practices: storing passwords in plain text.

“Never store passwords in plain text in your database,” says Tirthesh Ganatra, Co-Founder & Lead Developer at PriceBaba. “This is perhaps the most common mistake we have seen. Many large companies have been shamed in public for this kind of a lapse. Any compromise in your database should not put user data at risk, especially the passwords they use. Thus passwords and other important details of a user should be encrypted and stored in the database.”

7. Storing data unencrypted in your database

A good security rule of thumb: Assume you will get hacked. It’s not a matter of “if” a hacker will gain access to your database. It’s a matter of “when”. When a hacker accesses your database, how easily can they steal your data? When left unencrypted, this often leads to massive loss of personal and financial information.

“Just because the database engine requires a username and password doesn’t mean one cannot simply grab the data files and get the information from within,” says Raju Trivedi, Founder of privateborders.com. “And there is a reliance on the database engine’s security which if flawed would give hackers easy access. This is why so many big gaming and ecommerce sites get hacked and all the personal information including credit card data stolen so often.”

8. Passing variables through the URL path name

Here’s another dangerous, yet common practice: Many developers place variables in the URL itself, opening the door for hackers to exploit other applications or data. How big of a security risk is this mistake? As you’ll see from the story below, it’s huge.

“Never allow variables that a user interacts with to be part of a path name to a file on your system,” explains Kelley. “When auditing a web application, I was once able to exploit a system by making use of a link that allowed downloading a free sample of the product. Coded into the script’s URL was the path to a file to download. I changed the URL to reference a different file, and was able to download the file containing their passwords.”

9. Only performing authorization on the client side

As I touched on in a recent article, we’re seeing more and more development move towards the client side. While this creates faster and more powerful applications, it can create security problems if authorization is handled improperly.

“More web app developers are relying on the client-side browser to do work that was formerly done server side,” says Jarred White, CISSP, Manager of Security Engineering Services for ControlScan. “This creates a huge lack of control from a security standpoint, because you don’t know what kind of client is being used. It may not even be a browser at all. Anything that happens on the client side can’t be trusted, so you shouldn’t rely on Javascript or client-side code for critical functions, especially those involving payment information and other sensitive data.”

10. Assuming it won’t happen to you

Two of the most dangerous mistakes you can make when developing web applications: assuming your application won’t be attacked, or assuming you won’t make a mistake. Both of these assumptions lead to lax security practices. Always assume your application will be attacked, and that you will make a security mistake. This mindset will help you avoid future security breaches, and could possibly save your company from embarrassment or financial loss.

“Everybody makes mistakes,” says Campbell. “If you can find your mistakes before the hackers do, then you’re in good shape! Open source tools like the OWASP ZAP can help you scan your applications for common issues before you push to production.”

So, what do you think? Obviously, this list could be far longer, but I hope I’ve covered some of the most basic, yet important security mistakes. If you think anything should be added to this list, feel free to share in the comments.