Web application security: the complete 2026 guide

In 2025, account hacking became the leading threat for the businesses and non-profits helped by Cybermalveillance.gouv.fr, accounting for 21% of their assistance cases. The same year, the CNIL, the French data protection authority, received 6,167 data breach notifications, half of them caused by hacking. A web application concentrates everything an attacker is after: accounts, data and access from anywhere.

This guide to web application security is written for the person who commissions an application, not for the one who codes it. It sets out the measures expected by OWASP, by France’s cybersecurity agency ANSSI and by the CNIL, then the legal obligations that apply. At every step, it says what to demand from your vendor and how to check it.

🛡️ What is web application security?

The scope covers four things: the application’s code, its configuration, the data it stores and the exchanges between the browser and the server. It does not cover your team’s computers, your email or the services you use alongside it, which are handled separately. ANSSI defines information system security through three properties: availability, integrity and confidentiality. For a web application, they turn into checkable controls: who logs in, who sees what, what is encrypted, what is logged.

No official definition of the term carries authority, either at NIST or at ANSSI. The common reference is OWASP, whose reference documents are public: the CNIL asks that websites be protected against the risks in its Top 10.

The OWASP Top 10: the most frequent vulnerabilities

The ranking is now in its eighth edition. The 2025 one draws on data covering more than 2.8 million applications and on a survey of the community. Its ten entries are categories of risk, not specific flaws. OWASP gives fair warning: using it as a development specification means aiming for “the bare minimum”.

Compared with the 2021 edition, still quoted by most online guides, the software supply chain (A03) broadens the former category of vulnerable components. Mishandling of exceptional conditions (A10) is a new entry.

Brochure site, web application, business software: different exposure

A brochure site publishes pages anyone can read. A custom web application opens accounts, stores data and lets users act remotely. Custom business software adds your calculation rules, your approvals and connections to other tools. Each layer adds a surface to protect: credentials, permissions, exchanges.

⚖️ Who is concerned, and which obligations apply?

Any web application that processes personal data falls under the GDPR security obligation. The NIS2 directive targets certain companies of at least medium size, in listed sectors. The Cyber Resilience Act addresses manufacturers of digital products. Health and payment data have, on top of that, their own reference frameworks.

Every application that processes personal data: the GDPR security obligation

Article 32 of the GDPR applies to two parties: the controller, the company that decides on the application, and the processor that handles the data on its behalf. A vendor that hosts or maintains the application is one example. Both must ensure “a level of security appropriate to the risk”, including regular testing of how effective the measures are.

In the event of a data breach, Article 33 of the GDPR requires the CNIL to be notified “where feasible, not later than 72 hours”, unless there is no risk. Every breach is recorded in a register, even one that is not notified. Where the risk is high, the individuals are informed; encryption can remove that duty to inform, never the duty to notify.

A failure to meet these obligations carries a fine capped at €10 million or 2% of worldwide annual turnover. The higher amount applies, and it is a cap, not a price.

NIS2 and the Cyber Resilience Act: when your company or your vendor is covered

In listed sectors, the NIS2 directive targets companies with at least 50 people, or whose turnover and balance sheet exceed €10 million. The word “software” does not appear in it. What does appear is “ICT service management (business-to-business)”, which covers providers that install, run or maintain applications for their clients.

In France, the transposition law has not been enacted as of 15 September 2026. Adopted by the Sénat in March 2025, it is still waiting to be debated in the Assemblée nationale. Since March 2026, ANSSI has been circulating a framework of measures, still at working-document stage.

The Cyber Resilience Act, European regulation 2024/2847, addresses manufacturers of digital products placed on the market. Its obligation to report actively exploited vulnerabilities has applied since 11 September 2026, the rest of the regulation from 11 December 2027. Software as a service designed outside the responsibility of a manufacturer falls under NIS2. Custom-developed software, for its part, is not excluded from the scope.

When this guide is not enough

Two families of data fall outside the scope of this guide. Health data calls for a host holding an HDS compliance certificate, under a v2.0 framework now in force. Card payments come under the PCI DSS standard, which requires a penetration test at least every 12 months. In both cases, a compliance specialist steps in from the scoping stage.

🧰 What to gather before you start

Securing a web application starts before the first line of code, with a few short documents. The company knows which data will be processed, who accesses what and who decides in the event of an incident. The vendor supplies a requirements framework, the list of components and a backup plan. Without these documents, nothing can be checked on delivery.

What you put together in-house

These items belong in the software requirements specification, in the chapter on security requirements.

What your vendor must give you

To choose that vendor, the complete guide to custom software development walks through a project from end to end.

🛠️ Securing a web application step by step

Securing a web application takes seven steps spread across the whole life of the project. They run from threat modeling to monitoring, by way of access, inputs, data, configuration and testing. None is an end-of-project option, and each one can be checked without being a technician.

A realistic timeline

The steps attach to project phases rather than to weeks. No public source sets their duration, which depends above all on how sensitive the data being processed is.

Step 1: model the threats at the scoping stage

Threat modeling means answering, before any code is written, four questions set out by OWASP: what are we working on, what can go wrong, what are we going to do about it, did we do a good enough job? OWASP recommends running the exercise from the design stage, then at every change.

It is the answer to insecure design, which no tool detects exhaustively. In April 2026, ANSSI published a market study on integrating security into the development cycle, the S-SDLC or DevSecOps. It calls this “a major challenge for the 2025-2027 period”.

What you check: one page listing the sensitive data, the threats identified and their countermeasures, and the target ASVS level, in writing.

Step 2: authenticate, control access and protect the APIs

Multi-factor authentication is, according to OWASP, “by far the best defense” against most password attacks. The CNIL requires it for sensitive data, for administration and for connections from outside; ANSSI advises against SMS as a second factor. Without a second factor, the CNIL sets a floor of 12 characters of four types, or 14 characters without a special character.

Broken access control is the first category in the 2025 Top 10. The rule: deny everything by default, grant only what is needed, and check on the server side, where an attacker cannot alter the verification. APIs, which connect the application to other software, have their own OWASP ranking. Its 2023 edition puts access to data belonging to another user at the top.

What you check:

• multi-factor authentication, at least on administrator accounts
• one named account per person, no shared accounts
• a simple test: with a restricted profile, try to open a record reserved for another profile

Step 3: treat every input as hostile

Injection, the fifth category in the Top 10, happens when an input is executed as a command by the database or the browser. Against SQL injection, OWASP recommends the parameterized query and strongly advises against settling for escaped characters. Against script injection (XSS), it recommends the framework’s protections and output encoding; CSP is only an extra layer. Against request forgery (CSRF), you need tokens or the framework’s protection, as the SameSite attribute is not enough.

What you check: the framework and its protections, enabled and named by the vendor, and the absence of any SQL query built by pasting user input into it.

Step 4: protect the data and the secrets

A password is hashed, not encrypted: hashing is one-way, encryption reversible. OWASP recommends Argon2id and keeps bcrypt for legacy systems. Exchanges travel over TLS, the protocol that replaces SSL: ANSSI prefers TLS 1.3, accepts TLS 1.2 under conditions and rules out earlier versions.

Secrets, API keys and technical passwords stay out of the source code, and an exposed secret is revoked. Tests run on fictitious or anonymized data, in an environment separate from production. The guide to business software acceptance testing sets out the only exception the CNIL allows.

What you check:

• the password hashing algorithm, named
• the TLS version active in production
• where the secrets are kept, outside the code repository
• where the test data comes from

Step 5: remove what is not used, harden the configuration, keep dependencies up to date

Misconfiguration is the second category in the Top 10. The CNIL sets out the reflexes: unused ports closed, the database never reachable from the internet, no generic accounts. The HSTS header enforces HTTPS, the CSP header limits the resources a page may load. Error messages stay generic and reveal no technical detail.

Third-party components form the third category. OWASP asks that the version of every component be tracked, indirect dependencies included, along with an update plan for the whole life of the application. On GitHub, Dependabot alerts are included in every plan.

What you check:

• the list of components and the date of its last review
• the HSTS and CSP headers in production
• an error page with no software version on it

Step 6: test, through code review, automated analysis and penetration testing

Static analysis (SAST) examines the code without running it; OWASP warns that it detects only a relatively small share of vulnerabilities. Dynamic analysis (DAST) tests the application while it runs, from the outside. The penetration test, or pentest, run by a specialist, looks for what the tools do not see. The CNIL recommends testing regularly and before any new version goes into production.

In France, ANSSI qualifies audit vendors, the PASSI, for penetration testing and source code auditing among other things. Their official list is public and updated every month.

What you check: a dated test report, with the vulnerabilities and their fixes, and for a penetration test the scope in writing and the retest.

Step 7: monitor, back up and prepare for the incident

Without logging, an attack goes unnoticed. The CNIL recommends recording the creation, viewing, modification and deletion of data, with the author and the timestamp, and keeping those logs for six months to a year. It asks for one backup on a separate site, one offline, and regular restore tests. In the event of a breach, the vendor informs its client as soon as possible, and the company notifies the CNIL where feasible within 72 hours.

What you check: the date of the last successful restore test, the person who receives the alerts, and the written procedure in the event of a breach.

Running these steps alone takes a developer trained in security and time to verify each delivery. At OTTOPILOTE, everything starts from a brief of two or three sentences, with a free quote and a human reply within 24 working hours. After delivery, 30 days of fixes are included, then an optional monthly plan covers fixes, changes and security.

💶 How much web application security costs

Web application security has no single price: it breaks down into line items, the first of which is part of the development itself. No official source publishes a range for a penetration test. The lasting item is maintenance, which carries the security patches year after year.

The cost, line item by line item

Public contract amounts do not make a price list. Comutitres paid €2,550 excluding VAT to test an unsubscribe page, and the CIG Grande Couronne €35,000 excluding VAT for two web applications. France Télévisions awarded €229,655 excluding VAT for the france.tv platform. Neither the scope nor the number of days is published, and some amounts are maximums. Put to scale, the gap speaks for itself: these are not the same piece of work.

🧭 What a secure application guarantees, and what it does not

A web application secured to the reference frameworks reduces the risk without ever removing it. OWASP puts it bluntly: no tool covers its Top 10 exhaustively, and any promise of full coverage is “simply untrue”. The measures protect the application, not the people who use it.

Guarantees and limits

⚠️ The most frequent pitfalls

Six pitfalls regularly weaken the security of a web application, from scoping to day-to-day operation. Each has a simple fix, provided it is written down before signing.

Six pitfalls, and the fix for each

🎯 In summary

Only one decision is really yours: the level of requirement, and it is taken before signing, not after the first alert. The order that holds is always the same: list what the application will process, put that level in writing, have it appear on the quote, then sign off each delivery against dated evidence alone. Whatever was not written before signature gets renegotiated afterwards.

A safe application is not the one that promises zero risk: it is the one whose every protection can be proven, from scoping to day-to-day operation.

📚 Sources

• OWASP Top 10:2025: the list, the data and the recommended use of the ranking
• OWASP Cheat Sheet Series: passwords, injection, XSS, CSRF, authentication, secrets, headers, logging
• OWASP Application Security Verification Standard 5.0: verification levels
• CNIL, Personal Data Security Guide, 2024 edition: authentication, permissions, websites, backups, breaches
• CNIL, 2025 annual report: data breaches notified
• General Data Protection Regulation (EUR-Lex): Articles 28, 32, 33, 34, 82 and 83
• ANSSI, NIS 2 directive: scope and status of the transposition
• Cyber Resilience Act, Regulation (EU) 2024/2847 (EUR-Lex): timetable and scope
• Cybermalveillance.gouv.fr, 2025 activity report: threats to businesses and non-profits