This infographic summarizes best practices for building secure web applications. It outlines the top 10 application security risks according to OWASP, including injection, XSS, and insecure cryptographic storage. It provides a checklist of security measures for developers, such as input validation, access controls, and encryption. Specific examples are given for preventing XSS and SQL injection flaws. The infographic stresses that security is a process that requires thorough testing of all application components and controls.

1. Building Secure Web Applications Infographic
veracode.com/blog/2012/06/building-secure-web-applications-inf ographic/

9. Add this Infographic to Your Website for FREE!
Small Version
<p><a
href="http://www.v
eracode.com/pro
ducts/application-
security-
elearning.html"><
img
src="http://www.ve
racode.com/blog/
wp-
content/uploads/2
012/05/web-
security.jpg"></a>
</p>
<p>Infographic by
<a
href="http://www.v
eracode.com/">V
eracode
Application
Security</a></p>
Large Version
<p><a
href="http://www.v
eracode.com/pro
ducts/application-
security-
elearning.html"><
img
src="http://www.ve
racode.com/blog/
wp-
content/uploads/2
012/05/web-
security.jpg"></a>
</p>
<p>Infographic by
<a
href="http://www.v
eracode.com/">V
eracode
Application
Security</a></p>
Infographic by Veracode Application Security
the co$t of a data breach averages $5.5 million or $194 per customer record
Companies that take security seriously by employing a Chief Information Security Officer can reduce the cost per customer
record by up to 62%.
So…what can Web developers be doing to PREVENT these dat a breaches and Web application vulnerabilit ies from
happening in the first place?
The OWASP Top 10 Application Security Risks
Injection
Cross-Site Scripting (XSS)
Broken Authentication and Session Management
Insecure Direct Object References
Cross-Site Request Forgery (CSRF)
Security Misconfiguration*
Insecure Cryptographic Storage
Failure to Restrict URL Access
Insufficient Transport Layer Protection*
Unvalidated Redirects and Forwards
*May be outside the developer’s control
Application Security Checklist:
(This is not a comprehensive list, as application security is a constant process)
1. Does the application properly encode or escape data prior to exchanging it with external components such as a database,
LDAP server, web browser, etc?
2. Does the application encrypt sensitive information such as authentication credentials, sensitive customer data, etc. prior to
transmitting such information across the network?
3. Does the application comply with the organization’s existing security standards?
4. Does the application use thread-safe techniques to protect against race conditions that could harm system availability
and/or data integrity?
5. Does the application ensure that numeric values are within expected ranges that do not result in unanticipated
consequences when used in calculations or control structures?
6. Does the application properly control access to the server’s file system?
7. Does the application use currently accepted, industry-standard cryptographic algorithms?
8. Has the application been deployed with secure default permissions?
9. Does the application protect against brute force attacks?

10. 10. Does the application validate all input including parameters, arguments, cookies, anything read from the network,
environment variables, request headers, URL components, e-mail, files, database records and any external system that
provides data to the application?
11. Does the application verify the origin of sensitive requests through the use of unpredictable, unique nonces as hidden input
form values?
12. Does the application fail gracefully and securely without divulging details of the underlying implementation to the end user?
13. Does the application store state information on the server side only or ensure client-side state variables have not been
tampered with?
14. Does the application perform access control checks in a consistent manner across all potential execution paths?
15. Is the application free of hardcoded credentials and cryptographic keys?
16. Does the application use sufficient randomness for generating session ids or in other security-sensitive contexts?
Specific Examples of How to Combat Two Common Flaws
XSS (Cross Site Scripting) Flaws
You May Be Vulnerable If…
Input coming into your applications is not validated
Output to the browser is not properly escaped
How to Prevent It
Use the appropriate escaping method for the context you are in. Here are some examples:
HTML encode all user input returned as part of HTML
URL encode all user input returned as part of URLs (convert ?, &, /, <, >, and spaces to their respective URL encoded
equals)
Convert all user input to a single character encoding before parsing
SQL Injection Flaws
You May Be Vulnerable If…
Unvalidated user input is concatenated into an ad-hoc SQL query
How to Prevent It
Use parameterized prepared statements
Use Input Validation for Length, Type, Syntax & Business rules
Use the lowest privilege database account possible
Really Want Secure Web Applications? Security is a Process: Test Everything!
Never assume security controls are effective until you can validate them with thorough testing.
Most security vulnerabilities will not be discovered during normal application use.
Allocate time for dedicated security testing within your project timeline.
Always test applications and application components, both in isolation and in the environment where the application is
deployed.
Veracode Security Solutions