10 Common Web Vulnerabilities and How to Find Them

Every web application is a potential target. Whether you're running a startup or managing enterprise infrastructure, the attackers are scanning your perimeter, looking for the same vulnerabilities over and over again. The good news is that most of these vulnerabilities follow predictable patterns. Learn to recognize them, and you're already ahead of most developers.

This isn't a theoretical overview. We're going to walk through the most common web vulnerabilities, explain why they happen, and show you how to find them. No sanitized examples from textbooks. Real patterns from real applications.

Cross-Site Scripting: The Classic That Never Dies

XSS has been around for over two decades, and it's still everywhere. The concept is simple: an attacker injects JavaScript into your application, and it executes in another user's browser. The impact ranges from annoying to catastrophic, depending on what that JavaScript does.

The mistake developers make is thinking XSS only happens in obvious places like search boxes or comment forms. In reality, XSS can appear anywhere user input ends up in HTML output. That includes URL parameters, HTTP headers, JSON responses that get rendered, and data pulled from databases that was originally user-supplied.

Consider a typical scenario. Your application takes a product ID from the URL and displays it on the page. Maybe it says "Showing results for: iPhone 14" and that product name came from user input somewhere in the pipeline. If you're not encoding it properly, an attacker can craft a URL that injects a script tag instead of a product name.

The fix isn't complicated in theory: encode all output based on the context where it appears. HTML context needs HTML encoding. JavaScript context needs JavaScript encoding. URL context needs URL encoding. The problem is that developers forget, or they use a framework feature that doesn't apply encoding in their specific situation, or they build a custom rendering path that bypasses the usual protections.

When testing for XSS, don't just try the basic script tag. Modern applications often have filters or Content Security Policies. Try different contexts: inside HTML attributes, inside JavaScript strings, inside event handlers. Try different encodings and obfuscation techniques. The goal is to find a path where your payload reaches the browser and executes.

SQL Injection: Still Finding Its Way Into Production

You would think SQL injection would be dead by now. We've had parameterized queries for decades. ORMs abstract away raw SQL. Every security training mentions SQL injection in the first five minutes.

And yet, SQL injection keeps appearing. It happens when developers drop down to raw queries for complex operations. It happens in legacy codebases that were written before parameterized queries were standard. It happens in stored procedures where dynamic SQL is constructed. It happens in applications that use ORMs but occasionally need to write custom queries.

The pattern is always the same: user input gets concatenated into a SQL query string instead of being passed as a parameter. The attacker provides input that changes the query's logic. Sometimes they can read data they shouldn't access. Sometimes they can modify or delete data. Sometimes they can execute system commands on the database server.

Finding SQL injection requires understanding how the application interacts with its database. Look for endpoints that accept IDs or filter parameters. Try injecting single quotes and observe whether error messages reveal database details. Try boolean-based injections where you modify the query logic and observe changes in the response. Try time-based injections where you make the database sleep and measure response times.

Modern applications often use error handling that hides SQL errors from users. That doesn't mean SQL injection isn't present. It means you need to use blind techniques that infer results from application behavior rather than explicit error messages.

Server-Side Request Forgery: The Cloud Era Vulnerability

SSRF became critical when companies moved to cloud infrastructure. The vulnerability itself is simple: an attacker tricks your server into making requests to unintended destinations. On a traditional hosting setup, this might let an attacker scan internal networks. In cloud environments, it often leads to complete account takeover.

Cloud providers like AWS, GCP, and Azure expose metadata services on link-local IP addresses. These services provide temporary credentials to applications running on cloud instances. If an attacker can make your application request the metadata endpoint, they can steal these credentials and access your entire cloud account.

SSRF appears in any feature that makes server-side HTTP requests based on user input. PDF generators that fetch remote images. URL preview features that load link thumbnails. Webhook configurations that let users specify callback URLs. Integration features that connect to user-specified APIs.

The fix is straightforward in principle: validate and sanitize URLs before making requests. Block requests to private IP ranges and link-local addresses. Use allowlists instead of denylists where possible. But implementation is tricky. Attackers use DNS rebinding, URL obfuscation, and redirect chains to bypass filters.

When testing for SSRF, start with the obvious: try to make the application request an IP address you control and observe whether a connection arrives. Then try internal addresses like 127.0.0.1, 169.254.169.254, and private network ranges. Try different URL formats and encodings that might bypass validation.

Broken Authentication: Making Access Control Actually Work

Authentication vulnerabilities are less about clever exploitation and more about systematic failures in access control. The most sophisticated cryptographic system fails if the application lets attackers reset passwords without proper verification or continues sessions after password changes.

Common authentication issues include predictable password reset tokens, lack of brute force protection, session fixation vulnerabilities, and inadequate session invalidation. These aren't obscure theoretical attacks. They're practical issues that affect real applications every day.

Consider password reset flows. A secure reset mechanism generates a random, time-limited token, sends it to the user's verified email, and allows exactly one use. Weak implementations use predictable tokens based on timestamps or user IDs. Some don't verify email ownership. Some allow unlimited reset attempts, enabling brute force of short tokens.

Session management is equally important. Sessions should be invalidated when users log out, change passwords, or revoke access. Session IDs should be unpredictable and transmitted securely. Browser settings like httpOnly and secure flags should be set on session cookies.

Testing authentication requires methodical thinking. Check whether password reset tokens are predictable by requesting multiple resets and looking for patterns. Test brute force protection by sending many requests and observing rate limiting. Verify that logout actually invalidates server-side sessions. Check whether session cookies have proper security attributes.

Insecure Direct Object References: The Simple Flaw

IDOR vulnerabilities happen when developers implement authorization checks incorrectly or not at all. The pattern is simple: an application uses user-supplied identifiers to access objects but doesn't verify whether the requesting user should have access to that specific object.

Picture an application that displays account details at /account/12345 where 12345 is an account ID. If changing that ID to 12346 shows you another user's account, that's an IDOR vulnerability. The application checked that you're logged in but didn't verify that you own the account you're trying to view.

IDOR appears everywhere: document downloads, API endpoints, admin functions, file access, and any feature that uses identifiers to retrieve data. The fix requires implementing proper authorization checks that verify object ownership for every access attempt.

Finding IDOR is often just a matter of changing identifiers. Try incrementing numeric IDs. Try using IDs from other users' accounts if you have multiple test accounts. Try common IDs like 1, 0, or -1 that might access default or admin objects. Pay attention to all parameters, including those in headers of file paths.

Putting It Together

These vulnerabilities keep appearing because building secure applications is hard. Developers are under pressure to ship features, security training is often superficial, and it's difficult to maintain security awareness across large codebases maintained by changing teams.

The solution isn't just technical. Yes, use frameworks that handle encoding automatically. Yes, use parameterized queries. Yes, implement proper authorization. But also build security into your development process. Regular testing, code review for security issues, and ongoing training make the difference between applications that get breached and applications that don't.

RaSEC helps by automating the testing process. Our agents understand these vulnerabilities deeply and know how to find them in modern applications. They don't just match patterns. They think through the exploitation process and verify that vulnerabilities are actually exploitable.

But tools are just one part of the solution. Understanding these vulnerabilities yourself is equally important. When you know what attackers are looking for, you're better equipped to build applications that resist their attempts.