What Really Makes a Web Application Secure?

Are your Web Applications really secure? We all know the importance of protecting customers' sensitive information. But with data constantly moving in a Web Application, how can you be sure it is safe everywhere? Bill Goldsberry talks about the different places data needs to be protected in a Web Application, and things to look for in your own Apps.

Bill Goldsberry

a padlock and keyboard

Encryption, SSL, TLS, Ciphers and firewalls. There are so many pieces involved with keeping a web application secure, but what does it all mean? What do you need to know to keep your customer data secure and safe?

Before we look at how sensitive data is secured in a web application, it is important to have an understanding of where data resides, and where it flows while you’re using the application.

Flow chart diagram of a web application

In the diagram above, the User’s Browser sends requests to the Web Application over a secured internet connection using an SSL certificate. The Web Application processes that request and returns a response. The response could be a document to download, a form to fill out, or plain html data for the browser to display. This gives us three different areas we need to talk about when it comes to securing your data. Data needs to be safe while it is stored or at rest, and while it is being transferred. Outside of these two areas securing data is the responsibility of the code in the web application.

Data at Rest

When we talk about data at rest in respect to a web application, this is information that is saved in the web hosting environment. This could be files stored on a webserver, records in a database or other data physically saved on a server in the hosting environment. In a typical web application architecture, the web application saves and retrieves this data, and returns it to the requesting client, which is most often a web browser like Chrome, Edge or Firefox.  Securing data at rest is usually accomplished by encrypting the data while saved on the server. The purpose of encryption is to ensure if the hosting environment is ever compromised, the attacker cannot simply open a file or database record to obtain sensitive information without access to the encryption key.  In the diagram above, data at rest is represented in the File Server/ Database object.

Data in Transit

In our data flow diagram, data in transit is represented by the area between the end user’s web browser, and the firewall of the hosting environment. Any time data is traveling along this path, there is potential for the data to be intercepted by an attacker. A common attack of this type is called the man-in-the-middle attack. A full description of how this could happen can be read on the Open Web Application Security Project (OWASP) web site.
The purpose of securing data in transit is to ensure that data is not usable if an attacker intercepts the data while it is being transmitted between the web browser and the webserver.

Web Application Code

Arguably the most important, and the most difficult, piece of data security for a web application is how the application is architected and written. Ensuring data is secured while at rest on a server, and in transit between the server and client, is very important. However, it is all for not if the web application processing that data is not doing its part in keeping the data secure. The code for your web application has a lot of responsibility. It handles authentication (knowing who the user is), authorization (knowing what the authenticated user has access to and enforcing it), ensuring data is valid, and checking for potentially malicious submissions from a web browser. Regardless of the programming language used to create your web application, the developers need to write code with security in mind first.

There are countless methods hackers use to try to exploit potential vulnerabilities in a web app. If your application is vulnerable, it does not matter if sensitive data is encrypted at rest and in transit because your application will send back the data requested as if it were an authorized request. This helps illustrate why it’s so important to have a developer that is familiar with common web application vulnerabilities. OWASP maintains a list of top 10 web application vulnerabilities. OWASP Top 10

If your web app wasn’t written with these things in mind it is very likely vulnerable to one or more exploits.

So, what can you do as a customer?

This can be a lot to take in, but there are some things you can do as a customer to help ensure your data is safe. First, when selecting a vendor or developer to build your web app, be sure to ask some security-specific questions. Find out if they are familiar with the OWASP top 10 and some of the ways they go about preventing those exploits. If the vendor struggles to come up with an answer or isn’t familiar with the terms at all, it might be a good idea to look at other vendors. Also, ask about the use of automated scanning tools to find vulnerabilities. Depending on the type of sensitive data you are collecting, some regulations could even require that your web app has automated vulnerability scans completed.

The main thing is to make sure your vendor or developer knows about web app security and takes it seriously.

To make sure your web app is secure, contact me.

You Might Also Like