Web Application Security: The Ultimate Guide

Why is the question of security so crucial? Regularly many websites are down due to cyberattacks. Millions of passwords, email addresses, and credit card details were made public. These incidents always lead to losing users' trust and financial harm to website owners.

Web security aims to prevent cyberattacks. Effective website security requires careful attention to your web application, web server configuration, password generation and renewal policies, and client-side code.

Many publicly available vulnerability scanning tools can help determine if you've made any obvious mistakes. In this article, we'll consider such tools and steps you can take to secure your site.

What is web application security?

Like any software, web applications also have bugs and defects for a few reasons. Firstly, software engineers are human, and everyone can make a mistake. Aside from this, modern web applications contain many external libraries that may have some faults. For instance, the biggest open-source project, the Linux kernel, has an insane amount of bugs, and it's normal.

Nowadays, there are many different attacks that break or steal data from web applications. They do it through various application vulnerabilities.

The secure web application is the one that will be able to work as expected despite all attacks and still keep all data safe. Although the app can protect itself somehow, we also need some additional tools to keep it safe and protect it from attacks. Bad security mechanisms also can affect all other major application things like availability.

If you fail to protect your application from DoS or DDoS attacks, then if the attack happens, your app will become unavailable for some time.

Besides, things like that happen often, even in large IT companies. For example, GitHub was attacked by Chinese hackers in 2015, and they brought it down for 10 minutes in total. Peak traffic during this attack was about 1.35 terabytes per second. GitHub couldn't work for over 8 minutes. By its sheer scale, this was one of the most famous DDoS attacks in history.

So, no matter the scale and reputation of the company, no one is 100% safe from all attacks. However, we should be able to prevent the huge part of them.

In general, modern web applications have a lot of security vulnerabilities.

This article will provide statistics on the top app security risks by OWASP (Open Web Application Security Project). It is a foundation that investigates and shares a lot of articles, guides, and analytics about software security. Also, it creates open-source software projects for a lot of security-related use cases.

Why is security important in web applications?

Security in any part of the business is essential. It can save you a lot of money and time. Undoubtedly, every company has important data that can't be exposed. So, if you don't care about security well enough, you may lose money and reputation in the future.

For example, the Yahoo global company had a data breach in 2013. This giant lost about 120 million USD and affected 3 billion accounts. Even if your business is smaller, you will permanently lose both money and reputation if things like that happen.

There are other cases when sensitive data must be protected. The situation is you have payments in your application, and an attacker was able to steal data about credit card numbers. Can you imagine the repercussions of this and how your users will respond to this breach?

Also, sensitive data are kept in healthcare apps. In the case when healthcare data is stolen, the patient's medical privacy is violated. By law, with only a few exceptions, anything you discuss with your doctor must be kept private between the two of you and the organization they work for.

Besides that, in the modern world, there are a lot of different threats. They evolve all the time. So building security baselines, guidelines, and policies is very important.

The most common web application security risks

As we mentioned above, web threats are constantly changing, so staying on top of them is vital. One of the most important and valuable statistics for us is OWASP's top 10 web application security risks.

After collecting data from more than 40 well-known application security companies, OWASP published this "top 10" online. The ten most dangerous vulnerabilities were identified based on the information collected from more than 100,000 different programs.

We will discuss all these risks below. On the diagram, you can see their main changes.

Source: OWASP.org

• Broken access control. The attacks can happen when authenticated user permissions are misconfigured. So, a user may have more permissions than is needed. Thus, attackers exploit this and may steal data.

• Cryptographic failures. Usually, it's an issue with encryption in transit. For example, when you use HTTP instead of HTTPS or deprecated hashing algorithms like MD5 or SHA1. Hackers can easily steal passwords, credit card numbers, and anything you type on the website without encryption if your data is not encrypted in transit.

• Injection. Injections are one of the most common web hacking techniques. Injection attacks allow attackers to spoof identity, tamper with existing data, and even disclose all your application's data. So, this intervention can lead to data loss or severe changes in the database structure.

• Insecure design. The attack can happen due to the broad category of issues that can be expressed as a “missing or ineffective control design.” An example of this is not following architectural best practices.

• Security misconfiguration. The attack may happen due to default passwords, malicious libraries, or the existence of unnecessary components in the program.

• Application vulnerabilities and outdated components. The attacks may occur when you don't know the state of your current software. For example, it can be outdated, or libraries are not version-hardcoded. In this case, note that if you update those components, you must test them.

• Identification and authentication failures. These failures are related to session management. For example, using weak passwords or not securing your sessions well are chances that tokens may be reused later. So, hackers can steal your session credentials, break your application, or steal data.

• Software and data integrity failures. You must ensure that at every step of software development, you have integrity in your application. Use only trusted repositories. Also, ensure your code remains integrable during the CI/CD (continuous integration/delivery) flow. A CI/CD pipeline is an abstract automated series of steps that must be performed to test, build and deliver the application.

• Security logging and monitoring failures. It is often practiced not to look closely at logging and monitoring. Still, you must monitor API activity, sessions, and logins with the help of monitoring tools. So, you'll be able to see when the attacker was logged in and what actions they did. But remember to keep your logs clean from credentials or any sensitive data.

• Server-side request forgery (SSRF). It can be caused when an attacker can supply URLs that will trigger some action on the server. These actions can be anything, from reading application data to server metadata.

They say that informed means armed. Knowing different web security risks, you can take measures and prevent them. But what helps us to secure web products at Codica? We use AWS security services to prevent most attacks. Below we will consider them in detail.

AWS sustainability tools

Because we work only with AWS (Amazon Web Services), we will primarily discuss their solutions and a few external ones.

AWS has a list of services created to secure your web apps. By the way, we discussed architecture security in this article: DevOps Security Practices at Codica: How We Create Secure Web Products. Here we gave some recommendations about securing your infrastructure and networking.

Now, we will discuss tools and actions for keeping your AWS infrastructure sustainable.

AWS VPC

Amazon VPC (Virtual Private Cloud) is a service that enables you to launch AWS resources in a logically isolated virtual network that you determine. Our recommendations are:

• Configure your application and infrastructure to be in a private subnet with NAT (network address translation). So, your apps will have internet access, but to get to your server, you will need a bastion host or use sessions manager. The picture below shows what this setup looks like.

Source: Medium.com

• Make use of VPC ACLs (access control lists). In the picture we've shown above, you can see that services are placed in subnets. A subnet is just a smaller network inside your VPC. You can control access to it using VPC's built-in feature, ACL.

• Set up your VPC Security Groups in a safe way. For example, don't allow everyone to try logging in to your server. You can limit it to one IP address using Security Groups.

• Configure flow logs for your VPC. Flow logs will let you know who and when accessed any resources inside your VPC.

Source: docs.aws.amazon.com

• Don't make your database accessible over the internet. It can introduce a lot of problems. For example, if you accidentally share a password with someone, then they will be able to connect and dump it. So it's essential to make your database private and allow connection only from inside your project's network. Also, encrypt your database using AWS KMS keys. It's a service to create and control keys used to encrypt or digitally sign your data.

Source: docs.aws.amazon.com

AWS Security Hub

This service collects data from many other services like AWS Macie (a service used to inspect data in S3 and check for any potential leaks) or AWS Inspector (a vulnerability management service that continuously scans your AWS workloads for vulnerabilities).

Source: aws.amazon.com

This service will let you centralize a lot of your check results. It also enables you to check for compliance with popular security standards, like PCI DSS (Payment Card Industry Data Security Standard). It is an information security standard for organizations that handle branded credit cards from major card schemes.

You can also check compliance with the AWS Foundational Security Best Practices standard. You can see an example of such an audit below.

Source: docs.aws.amazon.com

AWS IAM

AWS IAM (Identity and Access Management) is a web service that also helps you securely control access to Amazon resources. AWS IAM is an important security topic.

You must ensure all users have multi-factor authentication (MFA). Configure account password policies and enforce password changes at least once a quarter.

Also, if you create an AWS IAM user for a developer that needs access to only one bucket, then filter permissions and give them access to only that S3 bucket. We always recommend using the least privileged principle. Thus, a subject should be given only those privileges needed to complete its task.

Also, IAM has a type of identity called IAM roles. They are used to give identity (with roles, it can be nearly any AWS service) the ability to perform calls to resources. Why do we use roles? They don't have usual credentials like username and password or access token. AWS creates sessions and generates security credentials for us.

In the end, to perform calls against the application, our application in AWS doesn't need credentials, only a proper role assigned to it. It will save you a lot of time because you don't need to rotate access and secret keys. Also, you can't expose them because you don't have them.

AWS Route 53

So, let's consider Amazon's Route53, a highly available and scalable Domain Name System (DNS) web service. Each web browser interacts through Internet Protocol (IP) addresses. DNS translates domain names to IP addresses. In such a way, the web browser can load online resources. DNS records are instructions that live in DNS servers and save information about a domain (its IP address and how to handle requests for that domain).

The AWS Route 53 service allows you to manage your DNS records and has a built-in DNSSEC (Domain Name System Security Extensions) feature. This feature will save web applications from DNS cache poisoning. It is when an attacker changes the origin of your domain and may redirect it to a malicious webpage. DNSSEC will help you to prevent these attacks.

AWS Web Application Firewall

WAF (Web Application Firewall) differs from the security groups or the web access control list we discussed before, protecting web applications. It can save you from many attacks we discussed in OWASP top 10, bots, and other web app threats.

WAF supports not only AWS-managed rules (for example, it can be even OWASP top 10 rule, a list of malicious addresses that will be blocked). It also supports other companies' rules on the AWS marketplace or custom ones you can create manually.

WAF works with CloudFront, Application Load Balancer, and API Gateway.

In general, WAF can protect you from a lot of different web attacks.

AWS Shield

Shield has two options, Default and Advanced.

The Default option always protects your CloudFront for free. With the Advanced option (which is not free), you'll get a support plan. Also, it will cover all scaling costs during attacks, support from AWS engineers, and you get a free WAF. Same as WAF, Shield works with a few resources, Application Load Balancer, a Global Accelerator, and Cloudfront.

AWS Cloudfront

We would recommend using AWS’s CDN (Content Delivery Network) solution. It is a group of distributed services that speed up the loading of web pages of high-load apps. It uses caching and distributes your application data between edge locations.

So, it will save you money by reducing the load from your origin server. CDN also partially protects you from DoS/DDoS attacks. Furthermore, it will also give you the ability to configure geo-restrictions and other features.

Which solution to apply?

So, if we combine all those solutions for web app protection, it will cost a lot. But none of those is a must. But we recommend putting at least CloudFront in front of your Load Balancer. Why? Because CloudFront is one of the cheapest cloud delivery network solutions out there. It will save you from a lot of attacks.

In combination with AWS and WAF, you'll get a lot of web app security features. So, you will be able to cover a lot of different scales. For example, Amazon's Shield was able to stop the most significant DDoS attack ever. To prevent and stop attacks, it is advisable to use web security tools and comply with the security requirements for software developers.

Let's take a closer look at OWASP’s top 10 proactive controls.

Web application security requirements

A security requirement is a statement of needed app security functionality.

Web application security requirements are derived from industry standards, laws, or previous experience. Those requirements should define actions and new or existing features to help secure your application from attacks.

For example, it can be PCI DSS (Payment Card Industry Data Security Standard) or HIPPA (Health Insurance Portability and Accountability Act). Also, it can even be OWASP's ASVS (Application Security Verification Standard).

Let's take a closer look at ASVS. In general, this standard has two main goals:

• Help organizations develop and maintain secure web applications.
• Allow security service vendors, security tools vendors, and consumers to align their requirements and offerings.

There are three levels of web app security in ASVS. The first level is for the low assurance level, and the third is for the most secure.

Source: OWASP Application Security Verification Standard 4.0.3

So, first-level actions will save your application from most modern attacks, including OWASP's top 10. And as they say, "it should be the bare minimum."

The second level needs much more action. Still, it is also far more secure and defends most software risks today. And the third level is reserved for healthcare, military, and other critical infrastructure.

We will consider some examples better to understand the difference between the first and second levels. In the second level, you must do the following:

• Verify that all your SDLC (Software Development Life Cycle) addresses security in all stages of development,
• Verify the use of threat modeling for each design change,
• Have centralized web application security control,
• Be sure that all middleware layers of the application are using an authenticated approach,
• Have a common logging format and approach.

This is just a small part of all requirements. There are many more of them.

Now let's briefly consider the requirements for the first and second levels. That is not a whole list of requirements, but some of the most important ones:

• Verify that your password corresponds to recommended requirements. It should be longer than 12 characters and shorter than 128. Ensure that your password field has a strength meter. It will induce users to create more complex passwords. Also, the password must be able to ‘age’ so the system enforces its change.

• Have a brute-force or account lockout defense. Don't let the user try to authenticate too many times in a given period. Besides that, build and integrate the CAPTCHA security measure. It is a Completely Automated Public Turing test to tell Computers and Humans Apart.

• Identify that system-given temporary passwords are at least six characters or more and that they expire.

Below we will consider steps to achieve great web application security. Use these practices to protect your application and infrastructure.

Web application security best practices in 2022

Now, let us take a look at some of the vital security best practices to follow in 2022.

Step 1. Leverage security frameworks and libraries

Nowadays, almost every programming language has a vast number of libraries. Not all are secure and can be trusted, so using only credible ones is highly recommended. Even if you use third-party libraries, keep a list of them. Also, keep all libraries up to date and reduce the attack surface.

Step 2. Securing database access

Ensure that the connection between the application and the database is encrypted and that it's not exposed to the internet. Also, verify that you use a good authentication mechanism or at least a strong password.

Step 3. Encode and escape data

It will help you to stop XSS (cross-site scripting) attacks. These attacks can happen when an app takes untrusted data and sends it to a database without a checking process. So, the attacker can insert malicious code into the database.

This XSS malicious code can steal or use a session cookie. This happens when executing a request from the client web page with the session cookie. The script can interact with the main web server as if it was the client itself.

Encoding, for example, with CSRF (Cross-Site Request Forgery) token, involves translating special characters into different but equivalent forms that are no longer dangerous to the target interpreter. Thus, we protect our code from possible XSS attacks.

Step 4. Validate all inputs

Input validation is conducted to ensure that properly formed data enter the workflow in an information system. Thus, we prevent malformed data from persisting in the database and the malfunction of components.

In general, data from all potentially untrusted sources should be subject to input validation.

You need to enforce the use of only allowed characters in input fields. Create the allow and deny lists. For example, postal codes in the United States must start with two numeric characters.

Step 5. Implement digital identity

A digital identity is used to determine the user before authorization.

To make the process of digital identity implementation secure, you can also use multi-factor authentication (MFA) and cryptographic-based authentication (CBA). These techniques provide an extra layer of web application security to identity and access management programs.

By the way, according to Microsoft, users who enable MFA are significantly less likely to get hacked.

Step 6. Enforce access controls

First of all, you should design your access controls upfront. All your requests should go through access control mechanisms. Use “deny” as a default principle along with the least privileged. Never hardcode credentials.

Sometimes an attacker uses a system of trial and error to guess valid user credentials. So, log each of the authentication and authorization events. Because sometimes, it can be an attacker trying to get your data using an authentication process.

Also, use secret managers like AWS Secrets Manager or Hashicorp Vault.

Step 7. Protect data everywhere

It would help if you defined the sensitive data and then built secure mechanisms around this data lifecycle. Examples may be credit card numbers, which must be well protected for known reasons. You need to encrypt them both in transit and at rest.

But remember that not all data must be encrypted. Why? Because it can slow the work of your web app. So, encrypt only sensitive data.

Looking for a reliable web development agency?

Our experts will create secure software for you.

Talk to an expert

Step 8. Implement secure logging

It is a relatively easy task in modern clouds. They have services that track all API activity (like AWS's CloudTrail). Also, don't log sensitive data or filter those credentials when configuring logging. Protect logs' integrity, make them read-only, and try to keep them all in one place (e.g., in CloudWatch or S3). Because then you'll have the ability to centralize their filtering.

Step 9. Handle all errors and exceptions

Modern web applications are complex and may have different responses to critical error states. For example, it can be losing a database connection. Surely, handling those errors right is essential to make your application secure. So, keep error messages for users brief and undetailed.

If the user can't log in, display the message “wrong password or user”. Because if you display “wrong password,” the attacker will use it to brute-force this account. Also, a leak of basic error handling can lead to the system shutdown.

Recommendations by Codica

At Codica, we always keep our finger on the pulse of web application security. We are glad to share our practices to help you keep your web product safe.

Helpful tools

Finally, let’s briefly sum up what tools we can recommend. If you are using AWS, they are obviously WAF and Shield we mentioned above.

Also, it would be good to use AWS Security Hub. Thus, you will collect data and metrics from many AWS security services.

We also recommend our clients add feature-rich secrets. There are a lot of them nowadays, and each is different. But be careful and watch if it's still maintained. Also, add a scanner and a container image scanner.

A container image security scanner will enable you to identify all the application vulnerabilities inside your container images. With its help, you can monitor containers regularly against any attack, issue, or new bugs. Containers are software packages that comprise all of the necessary elements required to run your software services in any environment.

Now let's talk about application testing.

There are a few types of web application security testing - static (SAST), dynamic (DAST), and SCA (Software Composition Analysis). Now let's consider them:

• SAST is available since the code starts to be written and analyzes the application's source code. Examples of these tools are Ruby's Brakeman or Python's Bandit.

• DAST. This type of testing attacks web applications from outside. You can use tools that scan the web apps, such as Abbey Scan, AppScan, AppSpider, and more.

• SCA. Almost all modern web applications have open-source components. Those components may have issues and bugs. You may think it's not that important, but you definitely heard about Log4 Shell, which is related.

Source: snyk.io

DevSecOps approach and philosophy

DevSecOps (development, security, and operations) defines practices that are almost essential in modern software development. However, we will only highlight the most important.

We all know that web app security operations can often slow down the development process. The critical thing here is to “shift left” the security operations. It means the efforts of DevOps to guarantee security in the early stages of web app development.

Indeed, this practice will introduce changes to your development pipeline. For example, you may deny deployment if the application has more than X security vulnerabilities.

Conclusion

In this article, we have discussed a lot of application vulnerabilities and tools to protect the apps. These are AWS security services we use at Codica, monitoring tools, feature-rich secrets, and more we mentioned above. These tools are all important, but you must balance each application and infrastructure part.

You need to consider and prioritize security. It means you must identify your business's threats and prioritize defending against them.

If you are looking for a reliable software partner that can develop and secure your web app in the right way, contact us.