Web apps are everywhere. With advanced tools, today it is not a problem to spin your application to facilitate your online customers or users. But this convenience also comes with risks. As soon as you log in, you are exposed to malicious users, hacking attempts, insecure use and damage that can lead to financial loss and the exposure of sensitive and confidential information. Implementing code checks and audits can protect your application against many online threats, otherwise these threats can be Achilles’ heel for your product.
Below we list common web application vulnerabilities. Knowing them can help not only secure applications, but also reduce the risk of financial and data loss.
Identification and authentication failures
Identification and authentication means that the user accessing the web application is a known user of the application. Unfortunately, while user registration is the key use case in most applications, however, this authentication failure tops the list of web application vulnerabilities. This issue occurs when authentication flows are compromised or so weak that hackers or malicious users can impersonate another user.
Insufficient session timeout
This vulnerability is most common with financial applications. The risk is that suppose a user has logged into the application but is either idle or has left their application open. This may allow unauthorized users to access it. This vulnerability can be mitigated by first enabling the short session timeout. After the timeout expires, the app automatically logs out the existing user and login is required again to continue using the app.
Unauthorized access control
It is not enough to know the user logging into the application. While user authentication is a must-have use case, user authorization is equally important. User permission means the user can do what they are trying to do. In other words, the user has the necessary privileges to perform actions. Proper access control and access based on roles and privileges can help secure data from unauthorized use.
Every application uses databases to store data. This data must also be recovered. This recovery is done via SQL queries to query the database. Normally, these requests require parameters from the application’s front-end forms. If the form inputs are not validated, hackers can write a query to the form inputs which can then be queried against the database. Although this vulnerability seems quite simple and obvious, it is still one of the most common security flaws.
Unlimited file upload and directory listing
We will see here how file manipulations can lead to security breaches.
File uploads are a common use case. Apps can ask their users to upload files such as images, text, or even document files. However, care should be taken that the file is not downloaded without proper authentication or authorization. Files should be scanned before being stored on the web server and the location of the files should be private if the content of these files is private or sensitive. Another common mistake is not validating the file type or size before uploading and allowing binary files to reach the web server.
Web servers allow you to list the contents of directories. This feature is useful in scenarios where multiple files exist, such as software versions. Users can choose the desired version (version being the name of the directory) and then download its contents. While this feature is useful, having unrestricted or public access to directories or exposing all directories can lead to web server intrusion. Malicious users can identify directory structure, naming conventions and file structure, etc.
Make sure you don’t leave any security holes in your application code. It’s easy to test your code for auditing and security purposes, but make sure the third-party libraries and code you’re using aren’t compromised either. As a general rule, make sure the libraries you use are actively maintained, have detailed documentation, an active and vibrant community, get frequent updates, and prompt support. Make sure you know the risks third-party code bring with him. Even the most tested and reputable libraries can have compromising code such as Log4Shell Vulnerability in Apache’s Log4j logging library.
Cross-Origin Resource Sharing Policy (CORS)
The cross-origin policy allows servers to only access resources located in the mentioned locations. These locations can be on the same server or on another server, but predefined. Having this policy in place can prevent web servers from accessing malicious or untrusted web resources.
Cross-site scripting (XSS)
Cross-site scripting allows hackers to introduce their malicious code into the web application. The code can be inserted via input forms, images or elements on the web page. Once inserted, this code can redirect users to illegitimate sites or transfer session or user information to hackers.
Exposure of sensitive or private data
Exposing sensitive data is a security leak that web application developers allow rather than being attempted by hackers. Such common scenarios are storing and transmitting unencrypted passwords, posting sensitive information on URLs, using insecure HTTP protocols, using weak encryption keys, storing keys public and private on the front-end application or the storage of financial information or clear-text passwords.
Security logging and monitoring failures
Finally, no matter how many backups are placed in the application, there is always a gap that can allow a security breach. This can happen even due to third-party vulnerabilities or insecure code. Applications should be monitored for abnormal behavior, intruders or ignoring warnings and logs. While securing the application should always be the priority, steps should also be taken to monitor the application in real time for compromise.