“It has HTTPS, so it’s secure.” That’s what most people think - and it’s exactly where the risk lives. Website security is not the padlock: it is every surface where the site touches the user or their data. There are three, and the site is only worth its weakest link: the connection (HTTPS and headers), the forms (where data comes in) and the payments (where the card and the money pass through). This article covers all three, with recent data from primary sources.
Key takeaways
- Security is not just HTTPS: most sites fail at the invisible basics - around 64% lack HSTS and 78% lack CSP (Web Almanac 2025).
- Attacks are automated and fast: automated traffic already exceeds half of the web (Imperva/Thales, 2025 - vendor study), and a disclosed flaw is exploited within ~5 hours, at the median (Patchstack, 2026).
- Forms are the least-locked door: they become spam relays, injection vectors and leak points for personal data (PII) - a direct risk under LGPD (the Brazilian data protection law).
- If you accept payments, the rule is: never touch the card. Payment pages hosted by the gateway take your site out of the crosshairs of e-skimming, which infected more than 11,000 domains in 2024.
- It costs dearly: the average breach in Brazil reached R$7.19 million in 2025 (IBM), and LGPD requires security measures and, under ANPD regulation, notification of relevant incidents within 3 business days.
The foundation: connection and headers
HTTPS is the floor, not the ceiling. Today around 88% of sites use HTTPS, but the layer that actually hardens the connection - the security headers - almost nobody implements. According to the Web Almanac 2025 (an independent analysis of millions of sites), only ~36% have HSTS and around 22% have CSP (in other words, ~64% without HSTS and nearly 8 in 10 without CSP). What each one does:
- HSTS forces the browser to always use HTTPS, blocking downgrade attacks and interception.
- CSP (Content-Security-Policy) defines which scripts the page is allowed to run - the main defense against XSS.
- X-Frame-Options prevents your page from being embedded in an iframe on another site (clickjacking).
- X-Content-Type-Options, Referrer-Policy and Permissions-Policy close smaller - but real - attack vectors.
And the certificate needs to be valid. An expired SSL certificate makes the browser stamp “not secure” on the page, scares visitors away and hurts rankings - Google has treated HTTPS as a signal since 2014 (Google Search Central). Worse: maximum certificate validity is set to drop drastically over the next few years (heading to 47 days by 2029, per the CA/Browser Forum decision), which makes manual management unsustainable. Automated renewal is no longer a luxury.
The favorite target: outdated CMS and plugins
Most business websites run on WordPress, and that is where the bulk of the attack volume lives. Among the sites Sucuri cleans up - a mostly WordPress customer base, so read it with that caveat - WordPress appears in the overwhelming majority of infections, and 39% were outdated at the time of the attack (Sucuri). And the problem is not the core: in 2025, Patchstack cataloged 11,334 new vulnerabilities in the WordPress ecosystem - 91% in plugins, 9% in themes and just 6 in core (Patchstack, 2026).
The reaction window is brutal: the median time between a flaw being disclosed and the first exploit is ~5 hours, and 45% of attacks happen within the first 24 hours (Patchstack, 2026). Since everything is automated - Wordfence alone blocked more than 54 billion malicious requests in 2024 (Wordfence) - updating “whenever there’s time” is not a strategy. The site needs a minimal attack surface (fewer plugins), disciplined updates and monitoring.
Forms: the door almost nobody locks
Every business website has forms - contact, quote requests, newsletter, résumé uploads. And almost everyone treats them as a front-end detail. That is a mistake, because the form is where untrusted data enters your system. The risks, according to OWASP:
- Injection (SQL Injection and XSS).A “message” field can receive code disguised as text. Without proper handling, an attacker reads or wipes your database (SQLi), or injects a script that runs in other visitors’ browsers (XSS). The defense is server-side validation (allowlist) and parameterized queries (OWASP - Input Validation).
- Email injection / spam relay.A poorly built contact form (using PHP’s
mail()without sanitizing) allows header injection and turns your site into a spam machine. This is not theoretical: Sucuri documented a case in which bots generated 149,700 emails from vulnerable forms (Sucuri, 2025). - CSRF. Without a protection token, an action can be forged from another site while the user is logged in (OWASP - CSRF).
- Malicious uploads. A résumé or quote form that accepts attachments is a doorway for webshells and malware. The OWASP rule: accept only the extensions you need (
.pdf,.docx), never trust the Content-Type, rename the file and store it outside the public directory. Never accept.exe,.zip,.htmlor.svg. - Bot spam. According to the Imperva/Thales report (2025), automated traffic reached 51% of web traffic in 2024 - it is a security vendor study, so read it as a strong directional signal, not a census of the entire web (Imperva, 2025). Even so, unprotected forms turn into dumping grounds. The effective defense is layered: honeypot (hidden field), rate limiting, and a modern anti-bot challenge (reCAPTCHA, hCaptcha or Cloudflare Turnstile) - none of them solves it alone.
And then there is the personal-data layer. Name, email and phone number in a form are personal data under LGPD (Law 13,709/2018). A form that dumps everything into a plain-text email creates a trail of PII with no access control, retention or disposal policy - the opposite of what Art. 46 requires. Collecting with a legal basis, transmitting securely and storing with controls is not extra diligence: it is the law.
Simple payments: where mistakes get expensive
More and more business websites accept some form of payment - a donation, a payment link, a simple checkout. And here there is a single, liberating principle: never touch the card.
The dominant attack today is e-skimming (or Magecart): a malicious script injected into the checkout page that steals card data as the customer types, before the transaction goes through - invisible on the server (Visa - Digital Skimming). The scale has exploded: Visa recorded +7% infected sites in the second half of 2024 (Visa PERC, 2025), and Sansec, the reference on Magecart, keeps documenting mass infections (Sansec).
It was because of e-skimming that PCI DSS 4.0.1 started requiring, as of March 31, 2025, control over payment-page scripts (req. 6.4.3) and tamper detection (req. 11.6.1) (PCI SSC). The good news for small sites: you can stay almost entirely out of scope. Using a payment page hosted by the gateway (redirect or iframe), card data goes straight to the gateway’s servers, never passing through yours - which is what qualifies the merchant for the simplest questionnaire (SAQ A) (PCI SSC). Gateways such as Stripe, Mercado Pago, PagBank and Pagar.me offer exactly this; Stripe, for instance, documents that its fields are rendered in hosted iframes and never touch your server (Stripe).
Two precautions many people get wrong:
- Never store card data. PCI prohibits storing the CVV, magnetic stripe and PIN - even encrypted. If you store nothing, you eliminate the target (PCI SSC - Data Storage).
- Watch out for scripts on the checkout page. The hosted iframe only protects you if the payment page is not contaminated by your own scripts (Google Tag Manager, pixels, analytics) - that is exactly how recent attacks bypassed the protection. In line with PCI (req. 6.4.3 and 11.6.1), the payment page is a controlled zone: avoid your own scripts whenever possible and, when they are unavoidable, keep them inventoried, authorized, justified and monitored for tampering.
The cost and the law
Why does all of this matter in hard currency? Because a breach costs, on average, R$7.19 million in Brazil (IBM, 2025) - and the reputational damage comes with it: around 70% of consumerssay they would stop buying from a brand after an incident. On the legal side, LGPD mandates technical security measures “by design” (Art. 46) and, under ANPD regulation, notification - within 3 business days - of security incidents that may cause relevant risk or harm to data subjects (ANPD - Resolution 15/2024), with fines that can reach 2% of revenue, capped at R$50 million per violation.
The bottom line
Website security is the sum of three surfaces - connection, forms and payments - and the site is only as secure as the weakest of them. An HTTPS padlock on top of a vulnerable form or an exposed checkout is not security: it is a facade.
The good news is that none of this is magic. It is engineering and discipline: HTTPS with headers and a valid certificate, a minimal and up-to-date surface, forms with server-side validation and anti-bot protection, personal data handled according to the law, and payments that never touch the card. Almost nobody does all three - and that is exactly where the difference lies.
At Inodus, A/A+ Security Headers and a secure architecture are a starting requirement - from the connection to the checkout. Want to see where your site is exposed? Run the free online audit.
Frequently asked questions
Isn't HTTPS enough for a website to be secure?+
No. HTTPS protects the connection, but not the forms, the uploads, the personal data or the payment page. Real security covers all three surfaces: connection, forms and payments.
What are security headers and why do they matter?+
They are instructions the server sends to the browser to block common attacks (XSS, clickjacking, connection downgrade). Most sites don't have them - around 64% lack HSTS and nearly 8 in 10 lack CSP (Web Almanac 2025).
How do I make a contact form secure?+
Server-side validation (not just in the browser), sanitization to prevent injection, anti-bot protection (honeypot + rate limiting + CAPTCHA/Turnstile), uploads restricted to safe file types, and personal data handled in line with LGPD, the Brazilian data protection law (OWASP).
My site accepts payments. Do I need to be PCI DSS compliant?+
If you use a payment page hosted by the gateway (redirect or iframe), card data never touches your server and you qualify for the simplest level (SAQ A) (PCI SSC). The golden rule is: never touch the card.
What is e-skimming?+
It is a malicious script injected into the checkout page that steals card data as the customer types (Visa). Using payment fields hosted by the gateway and keeping the checkout page free of your own scripts is the main defense.
How we interpret the sources in this article
This content distinguishes four types of evidence: official documentation, case studies published by recognized sources, proprietary market studies, and emerging research or analyses. Official data is treated as a normative reference. Proprietary studies and benchmarks are used as directional signals, not universal rules. Academic research and log analyses about AI are presented as evolving technical evidence, especially where vendors have not yet published defined thresholds.
Methodology and sources
Technical standards from primary sources: OWASPofficial (forms and injection); PCI Security Standards Councilofficial (payments); HTTP Archive - Web Almanacresearch/analysis (headers); Google and Visaofficial. Legal basis: LGPD (Planalto) and ANPD (Resolution 15/2024)official. Incidence data (Sucuri, Patchstack, Wordfence, Imperva)proprietarycomes from security vendors and is cited as such; the share of WordPress among infections reflects Sucuri’s customer base, not the web as a whole. This article is informational and does not constitute legal advice.