Common Web Application Attacks

Web applications are one of the most targeted surfaces by attackers. This is primarily because they are accessible over the internet, making them exposed and potentially vulnerable. Since these applications must be reachable to users, they also become accessible to malicious actors from anywhere in the world.

Attackers are free to explore the application, enumerate endpoints, and attempt a variety of attacks, such as SQL injection, cross-site scripting (XSS), and cross-site request forgery (CSRF). They may also try brute-force login attempts, session hijacking, or exploit misconfigurations and outdated software components.

Moreover, modern web applications often integrate with APIs, third-party services, and cloud infrastructure—each of which can introduce additional attack vectors. This wide and often complex attack surface requires organizations to implement a robust security posture, incorporating secure coding practices, regular vulnerability assessments, and runtime protection mechanisms.

In this landscape, understanding and mitigating common vulnerabilities—such as those listed in the OWASP Top Ten—is critical for reducing the risk of exploitation and protecting both user data and system integrity.

Here I wanted to list down most common web application attack types.

SQL Injection (SQLi)

What it is: SQL Injection happens when an attacker manipulates a web application's SQL queries by injecting malicious SQL code. If user inputs are not properly sanitized, attackers can gain unauthorized access to databases, extract data, or even modify or delete records.

Example:

SELECT * FROM users WHERE username = '$username' AND password = '$password';

If an attacker inputs admin' --, it can comment out the rest of the SQL query and log in without a password.

Prevention:

Use prepared statements (parameterized queries).

Use ORM (Object-Relational Mapping) libraries carefully.

Validate and sanitize user inputs.

Limit database permissions (least privilege).

Cross-Site Scripting (XSS)

What it is: XSS attacks occur when an attacker injects malicious scripts into web pages that are then served to other users. The script can steal cookies, session tokens, or perform actions on behalf of the user.

Example:

<script>alert('Hacked!');</script>

Based on the attack type, We can categorize XSS into following three types.

• Stored XSS In this type of XSS, the malicious input is permanently stored in the application database. For example consider a user entering a comment on a blog. These comments are stored on the database.

• Reflected XSS in this type, The script is not stored on the application but it is injected immediately to the page. For example consider a product searching page. In most cases the search term is included in the URL and it is used to display the content. Lets say

https://hacksland.net/search.php?str=monitor

The page content may be something like Search results for 'product'. If there is no proper input sanitization, we can inject a malicious javascript code into this parameter.

• DOM-based XSS For this type of XSS, there is no Backend is interacted. This occurs when the client-side JavaScript application is improperly handling user input.

Prevention:

• Escape all user input before rendering it to the page.
• Use frameworks that automatically handle escaping (e.g., React).
• Implement Content Security Policy (CSP).

Cross-Site Request Forgery (CSRF)

What it is: CSRF tricks a victim into submitting a malicious request unknowingly. If the user is authenticated, the application processes the request with the user's privileges.

Example: A malicious email link that causes a user to unknowingly transfer money.

Prevention:

• Use anti-CSRF tokens.
• Implement SameSite cookie attributes.
• Require re-authentication for critical actions.

Remote Code Execution (RCE)

What it is: RCE allows attackers to run arbitrary code on a server or application, leading to complete system compromise.

Example: If a web app allows users to upload files without proper validation, an attacker might upload a malicious script and execute it on the server.

Prevention:

Never directly execute user input.

Validate and sanitize file uploads.

Keep software and libraries updated.

Use safe APIs for executing system commands.

Remote Command Injection

What it is: Similar to RCE, but more specific: command injection involves injecting system-level commands through a vulnerable application.

Example:

<?php system("ping " . $_GET['ip']); ?>

If not sanitized, an attacker could execute:

http://example.com/ping.php?ip=127.0.0.1; cat /etc/passwd

Prevention:

Never concatenate user input with shell commands.

Use APIs that separate code from data (e.g., execFile instead of exec).

Validate and sanitize inputs.

File Inclusion Vulnerabilities (LFI/RFI)

What it is:

Local File Inclusion (LFI): An attacker includes local files on the server.

Remote File Inclusion (RFI): An attacker includes remote files, possibly from their own server.

Example:

<?php include($_GET['page']); ?>

Prevention:

Validate and sanitize filenames and paths.

Maintain a whitelist of allowed files.

Disable remote file inclusion (allow_url_include in PHP).

Broken Authentication

What it is: When authentication mechanisms are improperly implemented, attackers can compromise passwords, keys, or session tokens.

Example:

Predictable login URLs

Weak password reset mechanisms

Prevention:

Implement strong password policies.

Use multi-factor authentication (MFA).

Secure session management.

Avoid exposing sensitive information.

Security Misconfiguration

What it is: Default settings, unnecessary services, or incomplete setups can expose applications to attacks.

Example:

Directory listings enabled

Default admin accounts still active

Error messages revealing stack traces

Prevention:

Regularly review and harden server configurations.

Disable unused features.

Conduct security audits.

Insecure Deserialization

What it is: When untrusted data is used to abuse the logic of an application during the deserialization process, leading to RCE, privilege escalation, or replay attacks.

Prevention:

Never accept serialized objects from untrusted sources.

Implement integrity checks (e.g., signatures).

Prefer simple data formats like JSON over complex objects.

Business Logic Vulnerabilities

What it is: Attackers exploit flaws in the logic or workflow of an application (e.g., bypassing payment after purchasing items).

Prevention:

Conduct thorough security testing.

Understand and protect critical workflows.

Implement strict server-side validation.

Open Redirection

What it is: Open Redirection occurs when a web application redirects users to a different domain without properly validating the redirect URL. Attackers can use this to trick users into visiting malicious sites.

Example:

https://example.com/login?redirect=https://evil.com

User thinks they're clicking a safe link but gets redirected to a phishing page.

Prevention:

Validate redirect URLs against an allowlist.

Never accept full URLs from user input; only use relative paths.

Warn users before redirecting to external domains.

Insecure Direct Object Reference (IDOR)

What it is: IDOR happens when applications expose internal implementation objects (like database IDs) without proper access control, allowing attackers to access unauthorized data.

Example:

https://example.com/user/12345/profile

Changing 12345 to another user's ID can expose private information.

Prevention:

Implement proper authorization checks for every object.

Avoid exposing predictable identifiers (use UUIDs).

Never trust user-supplied input for authorization.

Server-Side Request Forgery (SSRF)

What it is: In SSRF, attackers trick the server into making HTTP requests to internal services that are not meant to be accessible externally (like metadata services).

Example: Accessing AWS metadata server:

http://169.254.169.254/latest/meta-data/

Prevention:

Validate and sanitize all user-supplied URLs.

Implement network layer filtering.

Block requests to internal IP ranges.

Sensitive Data Exposure

What it is: Applications sometimes expose sensitive data like passwords, credit cards, or personal info due to inadequate protection (e.g., no encryption).

Prevention:

Use strong encryption for sensitive data (AES-256, HTTPS/TLS).

Never store passwords in plain text (use salted hashes).

Apply strict access control on sensitive endpoints.

Clickjacking

What it is: Clickjacking tricks a user into clicking on something different than they intended by overlaying transparent frames or buttons.

Example: An invisible "Like" button over a video player.

Prevention:

Use the X-Frame-Options: DENY or SAMEORIGIN header.

Implement frame-busting JavaScript.

16. Cross-Origin Resource Sharing (CORS) Misconfigurations What it is: Incorrect CORS settings can allow unauthorized websites to interact with your APIs and steal data or perform actions on behalf of the user.

Prevention:

Always restrict allowed origins (Access-Control-Allow-Origin) to trusted domains.

Avoid using wildcard * unless absolutely necessary (and only for public APIs).

XML External Entity (XXE) Attacks

What it is: When an XML parser improperly processes external entities, attackers can read local files, perform SSRF, or execute other malicious actions.

Example:

<!DOCTYPE foo [<!ENTITY xxe SYSTEM "file:///etc/passwd"> ]>

Prevention:

Disable external entity processing in XML parsers.

Prefer safer data formats like JSON.

Broken Access Control

What it is: Access control issues happen when restrictions on what authenticated users are allowed to do are not properly enforced.

Example: Normal users can access admin endpoints simply by changing the URL.

Prevention:

Enforce server-side access control checks.

Deny by default, allow by explicit permission.

Prototype Pollution (mostly in JavaScript applications)

What it is: Prototype pollution allows attackers to manipulate object prototypes, affecting the behavior of the whole application.

Example: Sending { "proto": { "isAdmin": true } } in a request.

Prevention:

Use libraries that protect against prototype pollution.

Deeply clone user-supplied objects carefully.