Web app security basics in 2025: from AI protection to zero trust

Introduction: Why web security is critical again

Not long ago, the question of web application cybersecurity web applications was seen as something optional—like insurance: necessary, but not a priority. However, by mid-2025 the landscape had changed. With growing digitalization, any service accessible through a browser becomes an entry point not only for customers, but also for attackers.

According to the IBM X-Force Threat Intelligence Index 2024 report, more than 70% of all attacks last year targeted web applications, cloud infrastructures, and remote access services, with the biggest growth coming from vectors related to APIs and user authorization.

Verizon DBIR 2025 confirms that in 92% of attacks on web applications, attackers use stolen or compromised credentials, and highlights the rise in attacks on API interfaces as one of the leading intrusion vectors.

The picture is rounded out by the ENISA Threat Landscape 2024 report, according to which 34% of all successful attacks on digital services in the EU happen due to misconfigured security systems or the use of outdated components.

What’s behind these numbers?
Today, attacks have become not just widespread—they’ve become sophisticated. In some cases, attackers use large language models to generate exploits, bypass filters, and create phishing interfaces indistinguishable from the original. One documented case in Q1 2025 was an attack on a logistics SaaS provider, during which an AI algorithm automatically generated requests to compromise a REST API, leading to the leak of more than 1.5 million records, including payment data and geolocation tags. Such incidents are becoming less and less accidental and more and more repeatable.

According to Lisa Naylor, a senior analyst at Gartner specializing in web security,

“We’re seeing an increase in attacks not because there are more vulnerabilities, but because tools to exploit them have become available to everyone. The line between development and security no longer exists—every developer now needs to think like a security engineer.”

The question now sounds different: not “do we need to protect a web application,” but “when will it be attacked”.
If your site is accessible on the internet, it’s already in the crosshairs—and may be undergoing automated vulnerability scanning right now.

What should you do in this situation? Start by understanding which threats are most likely in 2025—and exactly how they get into code and infrastructure.

Top threats to web applications in 2025

When it comes to web application security, it’s important to understand this: vulnerabilities aren’t abstract risks, but very specific scenarios that are increasingly playing out in the real world. In 2025, not only has the attack vector shifted, but so have the principles attackers operate by. And if most attacks used to exploit basic validation errors or SQL injections, today the main focus has shifted to interactions between systems, including APIs, third-party services, and AI-based models.

You can learn more about approaches to building scalable and secure solutions here.

---

Attacks on APIs and microservices

APIs have become the standard for data exchange in web applications, especially in microservices architectures. However, this is where the largest number of vulnerabilities is found today.
According to the Salt Security (State of API Security, Q2 2025) report, 78% of organizations experienced API-related security incidents over the past 12 months. Moreover, on average, companies find 5–7 vulnerable API endpoints in their products each quarter.

Typical scenarios:

• Direct exploitation of insufficient authorization (Broken Object Level Authorization)
• Query parameter manipulation (Parameter Tampering)
• Injections via GraphQL or REST
• Undocumented “shadow” APIs left over from older versions

Case: in March 2025, an online insurance company (the name is not disclosed for legal reasons) found that a vulnerability in an API for an internal CRM allowed attackers to access more than 400,000 policies via simple identifier enumeration.

---

AI-driven attacks: from phishing to auto-generated exploits

2025 became a turning point in the use of AI in cyberattacks. We are no longer talking about hand-assembled scripts—today, LLM-based models not only write code but also optimize it to bypass security systems.

LLM-powered phishing has become almost indistinguishable from real interfaces—more than 60% of phishing pages pass even professional UX audits.

In addition, there are ready-made tools such as WormGPT, FraudLLM, and even closed bots on the darknet that can:

• Find weaknesses in public APIs and generate exploits
• Automatically bypass captcha
• Adapt to the target company’s language and style

Case: in February 2025, a major logistics SaaS service in Germany fell victim to an AI attack, in which a remote command with administrator privileges was executed via an auto-generated payload. The vulnerability was not in the code, but in the authorization order when processing attachments.

---

Supply chain attacks and third-party risks

Web application security stopped being just a question of your code a long time ago. Using external libraries, services, and SDKs creates a complex risk profile that is hard to control manually. In 2025, supply chain was the source of 12% of all serious incidents, according to the ENISA Threat Landscape Report (2025).

At risk:

• NPM packages without regular maintenance
• External fonts and scripts loaded directly from a CDN
• Libraries that auto-update in CI/CD

Case: in January 2025, a vulnerability in a JavaScript data visualization library widely used in business intelligence systems was exploited to plant a backdoor in the admin panels of more than 800 websites worldwide. The vulnerable package was pulled in automatically during the build, and almost none of the developers performed a manual review.

Attack types and affected industries (based on DBIR, Salt Security, and ENISA data)

Today, it matters less where the code lives and more what connections it has to the outside world. And the more connections there are, the harder it is to predict which one the threat will come through. But that is not a reason to panic; it is a reason to revisit which measures can realistically protect the application today.

5 mandatory measures to protect a web application

Understanding threats is only half the job. Real protection starts with a systematic approach to architecture and infrastructure, where security is not the “cherry on top,” but built into the foundation. Below are five key measures that in 2025 are no longer considered a best practice, but are seen as the mandatory baseline for any serious web application.

---

1. Using HTTPS and supporting TLS 1.3

If your app is still available over HTTP, it is a reason not just to be concerned, but to urgently revisit your infrastructure. In 2025, Chrome and Firefox browsers block access by default to pages without HTTPS if they transmit user data, and support for TLS 1.2 is being phased out across many public APIs and CDNs.

Practical tip:
Make sure all domains, subdomains, and staging environments use TLS 1.3 with a current certificate and HSTS (HTTP Strict Transport Security) enabled. Pay extra attention to old subdomains, test environments, and landing pages from past marketing campaigns—they often get forgotten and remain vulnerable.

---

2. Content Security Policy (CSP) control

CSP is a tool that lets you define where your site can load scripts, styles, fonts, and other resources from. It effectively reduces the risk of XSS attacks, especially when used in “block all except” mode.

However, its effectiveness directly depends on configuration accuracy. According to Google Web Risk, only 17% of the top 100,000 sites by traffic use a correctly configured CSP.

Practical tip:
Use CSP Level 3 with the default-src, script-src, frame-ancestors, and object-src directives. CSP Level 3 was published as a Working Draft W3C and in 2025 continues to be adopted in browsers with support for new directives, including trusted-types and require-trusted-types-for. This allows more precise control over JavaScript behavior and prevents unauthorized code injection at the browser level. Always enable the report-uri or report-to parameter to track violations in a safe sandbox before enabling strict mode.

---

3. Multi-factor authentication (MFA) and moving to WebAuthn

Passwords still remain one of the main points of failure in security. Even strong passwords don’t protect against phishing, keyloggers, and leaks via third-party services. The solution is WebAuthn and FIDO2—protocols that let you use biometrics, security keys, or built-in tokens instead of passwords.

The biggest market players, including Google, Microsoft, and Apple, have already moved to passkeys, which means users are getting used to the new standards as well.

Practical tip:
Add WebAuthn support at least for administrative and internal interfaces. Integration with libraries like simplewebauthn makes it possible to implement the functionality without significant time costs. MFA for users is not a burden, but a sign of trust in the service.

---

4. API protection: limits, authentication, schema validation

API is not just an interaction channel; it’s a door into the application. If it’s open too wide, the consequences are predictable. Proper protection starts not with a firewall, but with predictability and controllability of API behavior.

Practical tip:

• ✓ Use rate limiting based on IP and access keys
• ✓ Implement JWT with a short lifetime and rotation
• ✓ Apply data validation based on OpenAPI or JSON Schema
• ✓ Don’t publish unnecessary endpoints, even if they’re “temporarily disabled” — they’ll be found

---

5. Regular security audit and the use of AI vulnerability scanners

Static and dynamic security tests (SAST and DAST) are already part of standard CI/CD. But in 2025, a new category emerged: AI-driven scanners that can not only find vulnerabilities, but also prioritize them by risk, taking the application context into account.

According to Forrester Research, companies that implemented AI scanners in the pipeline reduced the number of critical incidents by up to 38% in the first quarter after implementation.

Practical tip:
Consider tools that integrate with GitHub Actions, GitLab CI, or Jenkins and support developer feedback right in the pull request. Among solutions with an AI module are platforms such as Snyk, DeepCode, and Code Intelligence.

Minimum web application security checklist for 2025

Ensuring basic security hygiene isn’t a one-time task, but a cycle built into the development process. Each of these measures not only reduces risk, but also demonstrates a mature approach to digital responsibility. Next comes the question: if the baseline protection is in place, how do you adapt the architecture to more advanced security models?

Zero Trust: how a security philosophy becomes the standard

In recent years, the term Zero Trust has been used actively in the context of enterprise security, but by 2025 it became an integral part of web development as well. It’s no longer a trendy phrase, but an architectural principle without which it’s hard to ensure a digital product’s resilience amid constant external activity.

---

What is Zero Trust: an explanation without abbreviations

Translated from tech-speak into plain language, Zero Trust means the system trusts no one by default, even if the user or component is already inside the infrastructure. It doesn’t matter whether the request came from a “known” IP, whether it uses a familiar session, or whether it was authorized an hour ago — every action, every access, every request is re-verified.

Instead of the traditional “trust but verify” logic, the opposite approach is used here: “don’t trust until it’s verified again”. This is especially relevant for microservice architectures, remote work, and systems operating over the public internet.

---

Why companies remain vulnerable without Zero Trust

Most major breaches in 2024–2025 happened not because an attacker guessed a complex password or bypassed a firewall. The problem started with the system trusting internal connections. One stolen token, one successfully compromised account—and the entire perimeter collapsed like a house of cards.

According to the Microsoft Digital Defense Report, more than 90% of attacks on cloud infrastructures started with legitimate but compromised credentials. If there is no system for re-verification and minimizing access rights inside the infrastructure, such an attack leads to escalation almost instantly.

Zero Trust reduces the likelihood of “attack sprawl” even in the case of a successful intrusion. And most importantly, it makes every user action visible and manageable.

---

How to apply Zero Trust in a web application

At the web application level, Zero Trust is implemented through several layers:

• Granular authorization. Not just “authorized / not,” but a clear understanding of what actions are available to a specific user, in a specific context. Use a role-based access model and a feature flags system.
• Minimizing privileges (Principle of Least Privilege). Even an administrator should not have access to all data and functions by default. Especially via the API.
• Environment and behavior checks. If a user signs in from an unusual device, IP, or time zone, that’s a reason to request re-verification. Such mechanisms are built in via risk-based authentication and behavioral analytics.
• Verification of every request. Use short-lived tokens, and be sure to implement authorization and signature checks on every internal API call, even between microservices within the same cluster.
• Logging and transparency. All access events must be recorded, be available for audits, and be analyzed in real time.

---

Case: a FinTech company and Zero Trust after a critical incident

In early 2025, a large European fintech company faced a leak that resulted from the compromise of a technical employee’s account. Through access to a Jenkins server, the attacker obtained administrative rights to the transaction management system in the test environment, and then in production as well, because the access was the same and there was no segmentation.

The company implemented Zero Trust within three months: it completely redesigned the permissions system, introduced environment segmentation, set up automatic verification of actions, and uses isolated access tokens for each infrastructure zone.
According to the CTO, this produced an unexpected effect— fewer internal mistakes and more transparency in how teams work, because now every access is not only protected but also explainable.

---

Zero Trust is not a set of specific technologies, but a strategic mindset. In web development it means the architecture is not just protected, but prepared for any part of the system to be attacked, and has a plan for it.

AI in cybersecurity: both enemy and savior

Artificial intelligence is already built into content recommendations, health analytics, CRM systems, and voice assistants. But arguably nowhere does AI’s impact show up as vividly and as inconsistently as in cybersecurity. And here we’re not talking about the future, but about daily practice—both for attackers and for those who oppose them.

---

How hackers use AI

Attackers quickly adapted to the capabilities of LLMs and generative models. Instead of manually enumerating vulnerabilities or studying documentation, they now use specially trained models that:

• analyze public API specs and find undocumented vulnerabilities;
• generate phishing emails and fake interfaces tailored to a specific company;
• select optimal payloads to bypass WAF and DLP filters;
• build infrastructure maps from external traces (DNS queries, CDN connections, service workers).

Examples of real AI-enabled attacks are showing up more and more often in Threat Intelligence reports. In April 2025, Recorded Future published data on a group using a fine-tuned GPT model to automatically identify vulnerabilities in open-source CMS. According to researchers, exploit generation time dropped from several days to 20–30 minutes after the initial scan.

---

How to defend: LLMs in the defender’s toolkit

But technologies have no moral coloring—and the same AI that helps attack can be used for defense. As early as today, companies are starting to use LLMs not just as an add-on to SIEM systems, but as an independent analytical layer capable of:

• analyze logs for behavioral anomalies and deviations from typical activity patterns;
• automatically classify incidents by likelihood of risk and criticality;
• generate patches for vulnerabilities based on source code analysis (auto-patching);
• trigger defensive scenarios in real time when access is attempted from suspicious sources.

This approach is already delivering results. According to the PwC Cyber AI Adoption Survey (March 2025), 46% of companies using AI in InfoSec reduced the average time to detect an incident (MTTD) from 8 hours to less than 40 minutes. In high-frequency infrastructures, this is equivalent to hundreds of thousands of dollars in savings per hour.

More and more often, companies include AI components not only in protection but also in the business logic of their services—hence the importance of proper integration and risk assessment at the architecture level. We cover approaches to security-aware AI development in detail in our projects.

---

Overview of new AI tools in InfoSec

Companies operating in the information security space are actively integrating AI into their products. Below are three solutions that set the standard in 2025.

Top 3 AI Tools for Cybersecurity in 2025

1. Microsoft Security Copilot
This tool is an LLM assistant built into the Microsoft 365 Defender and Azure Sentinel ecosystem. It helps security teams interpret incidents, decode threat behavior, prioritize risks, and suggest specific remediation steps. Especially valuable is the ability to work in natural language—specialists can ask questions directly without complex log filtering.

2. Palo Alto Cortex XSIAM
A powerful platform for automating SOC (Security Operations Center) operations that uses AI to correlate events, detect sophisticated attacks, and minimize false positives. XSIAM learns from historical data, builds behavioral models, and enables real-time responses to anomalies. It is especially effective in distributed infrastructures with high traffic volumes.

3. CrowdStrike Charlotte AI
Charlotte is a conversational AI assistant integrated into the CrowdStrike ecosystem. It analyzes endpoint device behavior, helps with incident investigations, and can explain technical details in plain language—for both engineers and business audiences. This approach makes Charlotte useful not only for analysts but also for CISOs who need to make decisions quickly.

Each of these tools shows that AI in defense is not a trendy module but an architectural necessity. It does not replace specialists, but strengthens their capabilities and reduces the time between an incident and the response. And in a context where attacks happen not monthly but hourly, this is a decisive advantage.

Case Studies: Who Has Already Lost and Why

Numbers, charts, and recommendations matter, but nothing conveys the nature of the risks as convincingly as real incidents. Below are three stories from different industries, each showing exactly how a vulnerability works in real life and why even technologically advanced companies can end up under attack.

---

FinTech: API Breach and Customer Data Leak

Cause: an undocumented public API
Vulnerability: lack of authorization control when accessing customer objects
Impact: compromise of personal and transaction data of more than 160 000 users
Case:
In January 2025, a fintech company providing B2B services for instant payments in Europe (unofficially mentioned as a Revolut partner) faced a critical incident. An undocumented API endpoint previously used for internal purposes was accessible from outside and did not require access-rights checks when a customer identifier was provided.

Attackers used an automated scanner to enumerate IDs and gained access to confidential information, including balances, transaction history, and linked cards. The vulnerability went undetected for more than two months.

Takeaway: even “unused” code requires the same level of protection as the public parts of the product. Any API, especially in FinTech, must be wrapped with an authentication system, and business logic must be validated at the access-model level.

---

Healthcare: medical data leak via a contact form

Cause: lack of data filtering and encryption on the server
Vulnerability: insecure contact form on the clinic portal’s homepage
Impact: leak of more than 50,000 patient medical records, including diagnoses, policy number, and email

Case:
In spring 2025, a private medical center in Southern Germany reported a large-scale data leak. The investigation found that the contact form on the website allowed file uploads, supposedly for “attaching test results.” In reality, all files were stored in an open directory on the server without authentication, and the URL to access them was generated in a predictable way.

As a result, thousands of PDF files containing test results and scans of passports were indexed by bots and partially ended up in search engines.

Conclusion: even basic user features—forms, attachments, field validation—require strict controls and regular reviews. When it comes to medical data, you can’t rely on an “secure by default” implementation.

---

eCommerce: phishing replacement of the admin panel

Cause: DNS record compromise via a hacked registrar account
Vulnerability: lack of multi-factor protection at the domain registrar
Impact: full control over the domain, phishing emails sent on behalf of the store, loss of the customer base

Case:
A well-known European online store with a million-user base fell victim to a sophisticated phishing scheme in March 2025. Attackers gained access to the domain registrar’s panel (by compromising corporate email), changed the primary domain’s A record, and redirected users to an identical copy of the site.

The main goal of the attack was to gain access to the CMS admin panel, and through it—to orders, customer databases, and payment information. Despite the team’s quick response, the fake site managed to process more than 12,000 user sessions in 7 hours.
According to the company’s security team, direct losses from lost orders, payment refunds, and infrastructure restoration totaled about 470,000 euros, not including losses from a drop in trust and the temporary suspension of payment gateways.

Conclusion: eCommerce security starts outside the website itself—with protecting domain records, the hosting panel, and administrative entry points. Using two-factor authentication, restricting IP access, and monitoring DNS changes aren’t recommendations; they’re must-haves.

---

Each of these cases shows: a technically successful company can lose not because it didn’t know about the threats, but because it underestimated the importance of one link in the security chain. And most often, that link is exactly the one that turns out to be vulnerable.

Technologies and standards that will be must-have by the end of 2025

Security technology keeps advancing, but certain tools and approaches are gradually moving from “nice to have” to mandatory. In 2025, a set of standards and technologies has taken shape that are expected in at least every mature web product—regardless of industry or scale.

---

OWASP Top 10: new focus areas and emerging risks

The updated OWASP Top 10 — 2024 list made it clear that the main focus is now not only on classic vulnerabilities like XSS or SQL injection, but also on conceptual design flaws. In particular, newer OWASP versions put special emphasis on:

• Insecure Design — lack of security at the application architecture design stage;
• API Security Misconfigurations — configuration errors, especially in public and integration APIs;
• Software and Data Integrity Failures — supply chain attacks and lack of dependency version control.

All of this reflects a new reality: security is no longer solved with patches—it starts with mindset.

---

WebAuthn, FIDO2, and passkeys: the end of the password era

Passwords as the primary authentication method are slowly but steadily fading into the past. In 2025, major players (Apple, Google, Microsoft) have already rolled out passkeys at scale—a standard based on WebAuthn and FIDO2 that lets you authenticate a user via biometrics, a built-in key, or an external token without entering a password.

Key benefits:

• ✓ phishing resistance — a passkey can’t be intercepted;
• ✓ device binding — an attacker won’t be able to use the key from another device;
• ✓ compatibility with browsers, mobile OSes, and desktops.

According to the Google Security Blog (May 2025), the number of successful phishing attacks against Google accounts protected by a passkey dropped by 96% compared to SMS-based MFA.

---

AI vulnerability scanners in CI/CD: security on the fly

Traditional vulnerability scanners that used to run manually or on a schedule are increasingly giving way to AI-assisted systems built directly into CI/CD pipelines. These tools can:

• run static and dynamic code analysis on the fly,
• prioritize vulnerabilities by risk level and potential impact,
• suggest possible fixes as a pull request,
• take the project context and business logic into account, not just technical signatures.

Such solutions are already being actively adopted in products from Snyk, GitHub Advanced Security, Code Intelligence, and others. According to the ENISA Threat Landscape Report, companies using AI-driven vulnerability scanning in CI/CD reduce the average time to fix a critical vulnerability by up to 72 hours — versus 12+ days with the traditional approach.

---

The shift to these standards is no longer seen as a trend — it’s the baseline that determines how ready your product is to operate in an open digital environment. And in the security context of 2025, the absence of any one of these elements doesn’t just reduce trust in the product — it increases the likelihood of an incident.

Web application security is not an isolated task, but an element of strategic growth. If you’re rethinking the role of IT in business growth, we also recommend reading our article “Digital Transformation 2025: How Technology Is Changing the Business Growth Trajectory” — in it, we looked at which technology solutions are becoming foundational for new business models.

Business checklist: are you ready for 2025?

Sometimes it can be difficult to objectively assess the security level of your web application. Processes like testing, audits, or rolling out new protocols can seem complete until you ask yourself specific questions. Below is a short 10-item checklist that helps you understand how well your system meets the security requirements of 2025.

The principle is simple: answer “Yes” or “No” to each question. If you got 6 or more “No”, it’s time to revisit your security strategy and approach — not for the future, but for right now.

---

✅ Web application security mini-checklist

1. Does your application use TLS 1.3 and HTTPS in all environments, including testing and internal ones?
2. Is a CSP (Content Security Policy) in place to protect against XSS and injections?
3. Is WebAuthn or passkeys supported as an alternative to passwords?
4. Is two-factor authentication (MFA) enabled for all administrative and internal accounts?
5. Are rate limiting and authentication used on all API endpoints, including internal ones?
6. Are automated vulnerability scanners with AI support integrated into the CI/CD pipeline?
7. Is there a regular audit of dependencies and components with supply chain risk assessment?
8. Are access rights in the system separated according to the least-privilege principle (Least Privilege)?
9. Is Zero Trust applied when designing interactions between components?
10. Are all access and security events logged, with the ability to perform retrospective analysis?

---

✔️ 6–10 “Yes” — you have a strong foundation and can move toward deeper adoption of the new standards.
⚠️ 3–5 “Yes” — your protection works partially, but there are still vulnerable areas.
❌ 0–2 “Yes” — the system is potentially insecure. You should start with an audit and an architectural review.

---

This checklist isn’t a universal audit, but it helps you spot gaps in a few minutes that could be costly. Because cyber threats don’t factor in budget, business size, or industry: they simply find the weakest link.

Conclusion: security isn’t a checkbox, it’s a strategy

Web applications have become the core of business: from finance to healthcare, from e-commerce to education. And the more deeply they’re embedded into day-to-day processes, the higher the cost of a mistake. In this context, security can no longer be treated as a set of measures “just in case.” It’s not a checkbox item. It’s not a protection subscription, but an architectural and management approach.

Security today isn’t something you can “add on” once the product is ready. It has to be built into the foundation: at the level of interface design, access logic, API handling, and data. Anything added afterward is more like damage control than real protection.

Small companies are especially vulnerable. They’re less likely to have dedicated specialists, mature processes, and backup budgets for incident response. But attacks don’t pick by size—automated scanners crawl thousands of sites looking for one vulnerable target. And very often they find it exactly where “there weren’t enough resources for security yet.”

Cutting security costs seems reasonable until you have to explain to customers where their data went, until payments get suspended, until headlines show up in the news. Rebuilding reputation costs more than protecting it.

It’s important to remember: security isn’t only about protection from external threats. It’s about trust, maturity, and respect for your own product and its users. And in 2025, the winners are those who realized this earlier than others.