Skip to Main Content
Resource Hub

Is Your Web App Protected from These Common Security Risks?

By Nikki Dent

Is Your Web App Protected from These Common Security Risks? 


When developing web applications, it’s important to make sure you’re taking possible security risks into consideration. This is a topic that our Lead Security Engineer, Nathan Buuck, takes very seriously. He was recently a featured speaker at the annual Indiana Tech Engineering and Computer Science (ITECS) Technology Conference on February 23, 2018, talking about common web app risks and mitigations.  


technology-security


Nathan spoke to a full audience of around forty students and faculty. His talk covered the top ten most common web app security risks as compiled by the Open Web Application Security Project (OWASP). On polling the room, Nathan learned that this was new material for most in attendance and he found he had an engaged audience. We don’t want you or your team to fall victim to these risks, so we’re going to take a closer look at a couple of the high-impact issues that Nathan sees most regularly.  


OWASP Top 10 Most Common Web App Security Risks 


  • A1-Injection 

  • A2-Broken Authentication and Session Management 

  • A3-Cross-Site Scripting (XSS) 

  • A4-Insecure Direct Object References 

  • A5-Security Misconfiguration 

  • A6-Sensitive Data Exposure 

  • A7-Missing Function Level Access Control 

  • A8-Cross-Site Request Forgery (CSRF) 

  • A9-Using Components with Known Vulnerabilities 

  • A10-Unvalidated Redirects and Forwards 


A Closer Look at Common Risks and Mitigations 


Of the ten total risk factors, Nathan identified three areas that he sees as being frequent risks that could have a big impact on the security of your web application. Those are A1-Injection, A-3-Cross-Site Scripting, and A-9-Using Components with Known Vulnerabilities.  


risk-areas


A1-Injection 

Area 1, Injection, actually encompasses five different types of common injection attacks: query injection, path traversal, command injection, unsafe serialization, and XML external entity references. Basically, an injection attack is when a malicious user attempts to input instructions into regular data fields, which your web app would then inadvertently execute. An example of this is inputting a SQL query to a username field. This could potentially create a vector through which someone could manipulate your data. To avoid this, always sanitize untrusted input. We also recommend using SQL parameterization, using stored procedures, and creating a whitelist for known, good inputs so that the application can reject other potentially malicious values.  


A-3-Cross-Site Scripting 

A similar problem is cross-site scripting, or XSS, which lets arbitrary JavaScript execute in the browser. There are a few ways to prevent this from happening. First, you should make sure that inputs are only allowed to use expected characters and sanitize “bad” strings. You can also render content using client-side frameworks, use a web application firewall, and add a Content Security Policy to your web application. 


A-9-Using Components with Known Vulnerabilities 

The third and final risk area that we’re going to look at is A-9 Using Components with Known Vulnerabilities. This is one that Nathan particularly promotes because, despite being low on the list, it’s the most prevalent risk he sees in security reviews. The threat model here is that you’ll bring in dependencies and tools without keeping them up-to-date with the latest versions that patch one or more vulnerabilities.  

“[This] is a pervasive issue in the industry as developers reference more and more dependencies using package managers like NPM without establishing processes to keep these dependencies up-to-date,” Nathan said.  

To help mitigate risks here, we recommend vetting all tools being used in development. Be skeptical about how well tools are being supported. Additionally, we recommend using sub-resource integrity (SRI) to cryptographically verify web dependencies that are retrieved from another server by the browser.  

Conclusion 


You can see from just these three risk factors the importance of keeping your web application secure. One of our best overall tips is to try to put yourself in the mindset of an attacker and think critically about your application as you work, looking for ways it could be exploited. Then you will build a more secure app from the start.  

If you want to learn more about web application risks and their mitigations, reach out to us! You can book a speaker or have our security team perform a review of your application. 


 

New Call-to-action

Interested in hearing more?