The OWASP Top Ten provides a powerful awareness document for web application security. The OWASP Top Ten represents a broad consensus about what the most critical web application security flaws are. Contributors include security experts from around the world who have shared their expertise to produce this list.

Below is a summary of the 2010 report - the previous having being in 2007.

1. Injection including SQL injection

   This occurs when untrusted data is passed in a query to a data process e.g. the famous param=' OR '1'='1 example put in a SQL query. The OWASP project also has some suggestions for protecting yourself against this attack - SQL Injection prevention cheat sheet.

2. Cross-site scripting (XSS)

   XSS is the most common web application security flaw. This occurs when an application includes user supplied data in a page sent to the browser, without properly validating or escaping that data. There are 3 variants:

   • Stored XSS - where the data is already in the application's data store e.g. in forums, CMS
   • Reflected XSS - where data is obtained from a user and displayed to another user
   • DOM-based/local XSS - attacks client side Javascript code and variables
   In the first two, the server serves a contaminated page to the client, while for the last the code is injected at the client end using Javascript.

   Note that using HTTPS is not a defence against XSS.

3. Broken Authentication and Session Management

   This could be from anonymous attackers wanting to gain access to other people's accounts. Insiders may also try this to mimick another user and thereby cover their tracks. Authentication can be tricky, and leaks or flaws in the authentication can be exploited. This risk can be minimised by having a single set of authentication and session management controls for developers on a project. An example interface can be found at ESAPI Authenticator and User APIs.

4. Insecure Direct Object References

   This is where an authorised person gains access to a prohibited resource simply by changing a reference in a web request e.g. changing some.site?reportid=1 (which is the user is authorised to access) to some.site?reportid=2 (which should be prohibited). This can be mitigated by using indirect references to restricted resources. The user can then only select from an allowed subset.

5. Cross-site Request Forgery (CSRF)

   A request is made to your site from another site, using forged HTTP requests. Such requests can be submitted via img tags. If the user is authenticated on your site, the attack could make changes to your site in the user's name. The changes should be restricted to only what the user is authorised to do. This risk can be mitigated by using hidden token for each HTTP request, which is validated when a user makes a request. A request is only allowed if the token validates. Such a token should at least be unique per user session - see CSRF cheat sheet.

6. Security Misconfiguration

   An attacker exploits default accounts, unused pages, flaws, unprotected resources to gain unauthorised access to or knowledge of the system. This attack could lead to compromising of the entire system. You can reduce this risk by making sure that default accounts are properly configured/disabled, error messages do not unnecessarily give away system configuration information, and system is kept up to date.

7. Insecure Cryptographic Storage

   This risk is mainly from authorised users of your system, including system administrators. The most common flaw in this area is simply not encrypting data that deserves encryption. When encryption is employed, unsafe key generation and storage, not rotating keys, and weak algorithm usage is common. Use of weak or unsalted hashes to protect passwords is also common. For hashes, SHA-256 is recommended over MD5 or SHA-1 - see Guide to Cryptography.

8. Failure to Restrict URL Access

   This is when an attacker can be granted access to a privileged page, simply by specifying the url, e.g. an anonymous user getting access to an administrator-only page. Mitigate by making authentication and authorisation role-based. Also allow for a flexible association between roles and permissions. By default, users should be denied access to restricted pages.

9. Insufficient Transport Layer Protection

   Requests not using SSL/TLS are open to network sniffing by a malicious user, which can lead to exposure of session IDs. This can be mitigated by using SSL/TLS for all requests. However, for performance reasons, it's more common to use SSL/TLS for the authentication stages only. A good practice is to use SSL/TLS for all sensitive pages, including administrative access. Also this TLS cheat sheet recommends not redirecting users from a non-TLS login page to a TLS login page.

10. Unvalidated Redirects and Forwards

    The risk is when a site redirects users based on some parameter in the request. Always verify the target of the redirect is a valid URL or page, and the user is authorised to access that page. If possible, avoid redirects altogether.

Generally, as a developer you can improve code security by:

• validating untrusted user input. If you must allow HTML in user responses, make sure to allow a small white list of HTML tags. Any tag that contains attributes should fail validation.
• generally rejecting input if it's not in an expected format. Sanitising the input has it's place, but you need to cover any escape codes that an attacker could use
• always using server-side validation in addition to client side validation. The latter can be by-passed, and thus cannot be relied upon.
• properly encode/escape all output, paying particular attention to HTML and attributes, XML and attributes, URLs, and Javascript (or other script)

You can download a the report at OWASP Top 10 for 2010.