Web security is neither an HTTPS lock nor a pre-launch scan. An application exposes code, identities, data, providers and operations; an attacker only needs an exploitable path between these elements.
1. In short: protect paths, not collect tools
Web cybersecurity is the set of design, development and operating decisions that prevent an unauthorized user or system from reading, modifying, deleting, diverting or making unavailable a service and its data.
It is judged by scenarios: does a client see another's file by changing an identifier? Does a compromised publisher account allow script injection? Is an integration capable of replaying a payment? Is a backup resistant to cloud account compromise? Does the team detect an unusual extraction?
A WAF, scanner and pentest can help. None replaces proper authorization, data minimization, change review, monitoring, or recovery.
2. Key figures: exploitation of vulnerabilities becomes a major gateway
| Data | Source and scope | What it allows you to decide | Caution |
|---|---|---|---|
| 31 % | Compromises starting with the exploitation of a vulnerability in the Verizon DBIR 2026. | Prioritize exposed components, exploitable flaws and patch time. | The DBIR brings together global contributors; your risk depends on exposure. |
| +55 % | Annual increase in this access route according to Verizon. | Reduce the window between disclosure, qualification and correction. | An unexposed vulnerability does not have the same urgency as an Internet service that is actively attacked. |
| 43 days | Median time to complete resolution of a critical vulnerability in the same corpus DBIR 2026. | Measure the true discovery-to-remediation time, not just the creation of the ticket. | The global median is not an acceptable target for an exploited vulnerability. |
| 48 % | Compromises involving a third party, after an annual increase of 60 %, Verizon 2026. | Include vendors, scripts, plugins, API and support access in the threat model. | Third party involvement covers different situations. |
| 48 % | Compromises involving ransomware, Verizon DBIR 2026. | Prepare segmentation, separate backups and reconstruction, even for a web service. | “Implies” does not mean that the website was always the entry point. |
| 4 875 incidents | Perimeter of theENISA Threat Landscape 2025, from 1er July 2024 to 30 June 2025. | Use a recent European landscape for availability, data and supplier scenarios. | The corpus reflects incidents known to the agency. |
| 3 586 events | Events handled by theANSSI in 2025, including 1 366 incidents. | Plan for escalation, qualification and coordination, not just prevention. | The ANSSI scope is not all French incidents. |
| 6 167 violations | Notifications received by the CNIL in 2025 ; one in two was due to piracy. | Link technical security, personal data, notification and subcontractors. | A notification sometimes covers very different volumes and causes. |
| 50 % | Share of controls and repressive actions that the CNIL plans to devote to data security in 2026, CNIL. | Document measurements and decisions, not just deploy tools. | A control priority does not prejudge a sanction. |
| 16 % | VSE-SME declaring at least one incident within twelve months, Cybermalveillance barometer 2025. | Include small structures in the preparation and test basic measurements. | Declarative survey: underdetection and memory bias are possible. |
| 3/4 | VSE-SMEs spending less than 2 000 € on cybersecurity according to the same barometer 2025. | Prioritize a few high-impact controls rather than an inaccessible catalog. | The declared budget does not measure exposure or effectiveness. |
| 10 categories | Perimeter of theOWASP Top 10:2025. | Use an awareness base for application risks. | OWASP reminds that ten categories do not cover all risks. |
These statistics should not be used to announce that “an SME will be attacked”. They justify a proportionate approach: knowing the exposure, protecting the most profitable paths for an attacker and preparing for recovery.
3. The path of a web attack: seven surfaces to close
3.1. Surface 1 — Exhibition: what responds on the Internet
Forgotten domains, test subdomains, consoles, API, buckets, ports and old versions expand the scope without always appearing in the CMS. Start with an inventory seen from the outside and bring it closer to the internal register.
Each asset receives owner, environment, technology, data, authentication, criticality and retirement date. An unknown service will not be patched or monitored. Automate DNS and certificate discovery, but have someone confirm the purpose.
Reduce exposure: administration behind strong authentication and appropriate restriction, non-public test environments, sober error messages, directories and backups not served, private storage by default. Protect domain and registrar with MFA, locking and managed contacts.
Exhibition question: does an external observer discover an asset that the team does not know how to attribute in less than an hour?
3.2. Surface 2 — Identity: accounts, sessions, and recovery
Authentication proves an identity; the authorization decides what it has the right to do. The most serious flaws often come from the second. Never trust an identifier, role, or price sent by the browser.
Enforce phishing-resistant MFA when the risk warrants it, block compromised passwords, limit attempts, protect recovery, and avoid shared accounts. Sessions must have duration, revocation, rotation after privilege change and cookies Secure, HttpOnly and SameSite adapted.
Construct a role-action-object matrix. Test horizontally — one customer to another — and vertically — a weak role to an administration function. Server-side authorization applies to every request and every object.
Authorization question: Does changing the identifier of a URL, a hidden field or a call API return data belonging to another account?
3.3. Surface 3 — Business logic: Is the code doing a permitted thing in the wrong way?
Scanners find certain injections better than abuse of the process. A reused coupon, indefinitely reserved inventory, negative refund, repeat vote, or skipped workflow can use perfectly valid queries.
Map the invariants: a payment only finances one order; an approval must not be given by its applicant; a quota does not go below zero; a transition requires the previous state. Apply these rules on the server side and, when necessary, in the database by constraint or transaction.
Protect against replay, concurrency and automation: idempotency keys, throttling, velocity detection, adapted lock, expiration and independent confirmation. CAPTCHA sometimes slows down certain abuses; it does not guarantee the business rule.
Logic question: what happens if the same action is sent twice, out of order, very quickly or with an extreme value?
3.4. Surface 4 — Data: collect less, partition better, exit cleanly
Inventory the data really needed, their purpose, duration, sensitivity and recipients. Minimization simultaneously reduces cyber risk, load RGPD and impact of an incident.
Encrypt in transit and at rest depending on context, but above all protect keys and access. Separate environments; production data should not be copied into a test without justification and transformation. Use parameterized queries, schema validation, encoding in the right context and strict upload policy.
Log sensitive access and exports. An extraction of ten million rows should not resemble a normal consultation. Prepare deletion, restitution and notification with the DPO; bonds are not discovered during the crisis.
Traceability question: does the company know how to explain who exported what data, when and by what route?
3.5. Surface 5 — Software chain: dependencies, build and providers
The site integrates open source code, packages, images, plugins, marketing scripts, fonts, CDN and API. The third party is not external to the product: it sometimes runs with its privileges and data.
Maintain component inventory, lock versions, protect registries and CI/CD, sign or verify artifacts according to risk, then separate build and production rights. Analyze dependencies before merging and regularly after, because a healthy version today risks receiving a vulnerability tomorrow.
For third-party scripts, ask for purpose, data, owner, alternatives and removal plan. A tag added for a campaign sometimes remains for several years. Content Security Policy, Subresource Integrity in suitable cases and reduction of authorized domains limit certain scenarios.
The NIST SSDF organizes practices around preparation, protection, secure production and response. It provides a program basis; the threat model chooses the necessary depth.
Useful test: Can a compromised critical dependency reach production secrets or release without second approval?
3.6. Surface 6 — Operation: configuration, detection and restoration
Robust code risks being weakened by an exposed key, an open console, a public bucket, or a network rule that is too broad. Version the infrastructure, define baselines and detect deviations.
Centralize useful logs: authentications, access denials, role changes, administration, exports, errors, WAF and deployments. Protect their integrity, synchronize clocks and set retention. An alert should indicate what to check, not just that an abstract threshold has moved.
Backups must be separated, protected and restored. Prepare a clean environment, dependencies and rebuild order. Ransomware does not resolve with an inaccessible or contaminated copy.
Useful test: can the team detect an admin account logging in from a new country then exporting all data?
3.7. Surface 7 — Answer: decide under pressure
The plan specifies incident manager, alternate, out-of-band channels, service providers, legal, DPO, insurer and relevant authorities. It contains severity criteria and powers: cut a function, revoke sessions, isolate an integration, restore or inform.
Preserve evidence before cleaning. Document timeline, decisions and impact. Regular, factual communication without premature cause protects trust better than silence followed by certainty.
After restoration, correct the cause and contributing factors. The countertest must demonstrate that the path was closed without breaking the service. Share learnings with product, development and operations.
Useful test: during an exercise, how long does it take to convene decision-makers, revoke access and confirm a restoration?
4. Web security tests: produce proof, not a volume of findings
The scanner detects. The review contextualizes. The pentest continues. The counter-test confirms.
These four operations have neither the same coverage nor the same objective: the automated analysis only processes known families, the review examines architecture and logic, the intrusion test attempts to exploit paths on a defined perimeter, then the countertest verifies that the correction effectively closes the scenario without creating a new regression.
A useful report distinguishes observation, operating condition, impact, reproducible evidence and recommendation. It avoids adding up a hundred weak pieces of information to produce an impressive “risk score”. Above all, management must know which paths are open, which losses become plausible and which decision reduces the risk within the time frame compatible with the exposure.
Perimeter matters. A lot. An untested API, a forgotten role or an excluded environment remain inconclusive. The sponsor must therefore compare the actual inventory, sample retained and limits before interpreting a lack of discovery as an absence of vulnerability.
5. Minimum measures according to the risk of the service
| Level | Example | Expected base | Additional insurance |
|---|---|---|---|
| Low | Editorial site without account or sensitive data. | MFA admin, updates, backup, HTTPS, domain control, protected forms, logs. | Regular scan and review of third-party scripts. |
| Moderate | Lead site, multi-author CMS, CRM. | Weak base + roles, anti-abuse, secrets management, test environment, supervision and violation procedure. | Targeted code review, authorization testing and exercise. |
| High | E-commerce, customer portal, important personal data. | Secure SDLC, threat model, segmentation, logs, recovery, monitoring, vendor management. | Independent pentest before major launch and after critical change. |
| Review | Complex payment, health, infrastructure or sensitive rights. | High controls + sectoral requirements, redundancy, response team and strong traceability. | Regular audits, adapted red team, crisis tests and reinforced supervision. |
The classification does not depend on the size of the company. A small service is likely to process sensitive data or concentrate all revenue.
6. Recommended Method: Integrate Security into Four Product Decisions
6.1. Cadrage — define unacceptable losses
Identify assets, plausible attackers, paths, impact and obligations. The deliverable is a threat model readable by management, linked to the backlog and accepted risk criteria.
6.2. Design — remove or contain paths
Minimize data and privileges, choose proven services, draw boundaries, degraded modes and logs. Conduct an architectural review before costly choices become irreversible.
6.3. Delivery — prevent regressions
Add security criteria to stories, reviews, unit and integration tests, code/dependency analysis and secrets control. The tools detect; a person qualifies the usability and context.
6.4. Operational — prove control holds
Monitor, test alerts, restore, patch, and review entitlements. Track exposure and residual risk, not just the number of open vulnerabilities.
7. Prioritize vulnerabilities without drowning
Technical severity is just one input. Use at a minimum: known exploitability, Internet exposure, required privilege, data sensitivity, business impact, compensating controls, and difficulty of remediation.
| Location | Priority | Decision |
|---|---|---|
| Flaw exploited, component exposed, path confirmed | Emergency | Isolate or correct immediately, monitor for signs of exploitation. |
| Theoretical criticism, function disabled or not reachable | High but contextualized | Verify non-exposure, plan remediation, and document exception. |
| Low score, but allows access to a sensitive object | High | Correct the authorization; the generic score underestimates the business logic. |
| Dependency without patch, replaceable use | Exposure reduction | Disable, filter, isolate or replace; follow the release of the patch. |
| Information without impact path | Bass | Group, correct in maintenance, avoid alert noise. |
The DBIR median time of 43 days should not become a norm. An actively exploited vulnerability sometimes requires a response within hours; a risky, unexposed update requires controlled testing.
8. Logiks advice: the starting point for an SME
- own domains, cloud accounts and repositories;
- MFA and registered accounts for administration, email and code;
- inventory of exposed assets and versions;
- separate backup with quarterly restore;
- accelerated procedure for exploited vulnerability;
- authorization tests on each role;
- logging of sensitive access, exports and changes;
- annual incident exercise with management, technical and DPO.
This basis does not replace the analysis specific to the service. It creates a foundation that the company really knows how to maintain.
9. Road Map 30 / 60 / 90 Days
9.1. Days 1 to 30 — See the exhibition
- inventory domains, applications, API, accounts and suppliers;
- classify critical data and paths;
- fix orphaned access, MFA, backups and exposed test assets;
- build three priority threat scenarios;
- name owner and risk accepted.
9.2. Days 31 to 60 — Close probable paths
- test authentication, authorization, upload, integrations and business logic;
- address exploitable vulnerabilities and critical dependencies;
- secure CI/CD, secrets and administration;
- install logs and alerts;
- document deployment, rollback and restoration.
9.3. Days 61 to 90 — Prove the answer
- carry out a targeted pentest if the level justifies it;
- cross-test corrections;
- restore an isolated backup;
- simulate account compromise and extraction;
- include security and debt in the monthly product review.
10. FAQ
10.1. How to secure a website?
Start with inventory, administrator accounts, updates, tested backups, rights, forms and logs. Then add threat model, business logic testing, delivery security and response based on data and criticality.
10.2. Is an HTTPS certificate enough?
No. HTTPS protects the transport between browser and server. It does not fix broken permission, injection, compromised account, excessive data, vulnerable dependency or unusable backup.
10.3. Should we do a pentest?
Yes for a risky application, before a major opening, after a significant change or when a requirement requires it. The pentest samples a perimeter on a date; it complements secure development and operation, without replacing them.
10.4. How quickly to fix a vulnerability?
Depending on exploitation, exposure and impact. An actively exploited Internet vulnerability sometimes requires immediate isolation or remediation. Set targets by risk, measure from detection to deployment, and document exceptions.
10.5. Who is responsible for cloud security?
The provider protects the layers defined by its service; the customer remains responsible for numerous settings, identities, data, application and uses. The boundary varies between IaaS, PaaS and SaaS and must be written.
10.6. What’s the difference with a cybersecurity audit?
The cybersecurity department sets up and operates protections. The audit examines a scope, collects evidence and formulates independent findings at a given time. One builds; the other evaluates.
11. Conclusion
Web cybersecurity consists of preventing a technical path from becoming a business loss. It starts with what is exposed, crosses identities, rules, data and providers, then is verified in exploitation and response.
The best defense is not the longest list of tools. It is a small number of controls linked to scenarios, owned by people and regularly tested.
12. Main sources
- Verizon — Data Breach Investigations Report 2026, may 2026.
- Verizon — Infographic PME DBIR/BIS 2026, June 2026.
- ENISA — Threat Landscape 2025, October 2025, revision January 2026.
- ANSSI — Overview of the cyber threat 2025, March 2026.
- CNIL — Annual report 2025, may 2026.
- Cybermalveillance.gouv.fr — Barometer of cyber maturity of VSEs-SMEs 2025, October 2025.
- Cybermalveillance.gouv.fr — Activity report and threat status 2025, March 2026.
- OWASP — Top 10:2025, accessed on July 13 2026.
- NIST—Secure Software Development Framework 1.1, accessed on July 13 2026.
- CNIL — RGPD Developer Guide, updated January 2025.