The web is the portal to business. It’s still true that the browser can talk to backend servers, but more and more applications use web protocols to connect to one another. These webs-of-applications form the basis for many information architectures today.

Regardless of whether it’s a user filling out a form, a piece of Javascript processing transaction data before sending it to a server, or two servers exchanging information, anytime there is a network link between systems vulnerabilities are likely to creep in. Add layers of middleware to the mix and the problem grows.

Application vulnerabilities can happen in all types of systems. For most developers today, web vulnerabilities are the most common. Application vulnerabilities have existed since the first web server permitted a user to provide input to a backend. In the early days these were generally related to input validation. That’s still true today.

The Open Web Application Security Project (OWASP) Foundation is a not-for-profit charitable organization behind the project, which collects information about web application security challenges and provides information about how to avoid them.

OWASP Top 10


Each year since 2013 OWASP has published a “top 10” list of security vulnerability classes. These have evolved over the years as technologies have changed. What’s common to all 10 is that web application developers have a hand in preventing vulnerable code from going to production by applying secure coding techniques. You can, and should, read about the OWASP Top 10 at

One class of attack that has not changed since the foundation of OWASP is Injection. These occur when untrusted data is sent to an interpreter as part of a command or query. The attacker’s hostile data can trick the interpreter into executing unintended commands or accessing data without proper authorization. There are ways to prevent this, and OWASP publishes information about how to implement those best practices.

One of the valuable OWASP resources that developers can use is the collection of “cheat sheets.” Cheat sheets are short documents that describe actionable steps to avoid common vulnerabilities including injection. There are dozens of sheets that detail processes for specific use cases. You can find a master cheat sheet with pointers to others at

OWASP is the most well-known starting point to understand application vulnerabilities and how to avoid them. It would follow that many books and training courses have been written that follow OWASP as an outline.

Two training resources available on campus are SANS training and LinkedIn Learning (formerly The Office of the CIO procures a limited number of seats for SANS Developer training. Contact the Chief Information Security Officer for availability of seats. The SANS course is approximately 3 hours of computer-based training that covers the OWASP top 10 as well as other topics like version control and testing. offers several classes in secure software development. These are available at no cost to campus staff members. You can link to through the UCSB Learning Center. Search for “secure software development.”

Testing and quality control are part of any well-managed software development project. There are tools available to help test web applications for many of the vulnerabilities in the OWASP top 10. The campus already gets the benefit of some public services, such as Dorkbot from the University of Texas, which automatically and periodically scans for injection vulnerabilities. If any are discovered, the UCSB Security Operations Center (SOC) will notify the security contact for the network segment where the server is located.

Application developers should consider other tools and methods to test during the development and release processes. OWASP publishes a testing guide. There are many open-source and commercial tools that are available.

The SOC maintains a license for which includes a limited set of licenses for web application scanning. Development teams can request a scan of a complete application in a dev/test network by contacting the SOC ( These tests can take hours to days to complete depending on the complexity of the application. These tests should be run prior to move-to-production, however they are not suitable for iterative tests during development.

Development teams should consider fully implementing open source tools for licensing one of the many available cloud or on-premise testing tools available. The OWASP testing guide has a directory of tools at