The Attack Baseline Every Small Website Already Faces
A newly exposed cloud server gets its first probe in about 52 seconds. Small website attacks are automated and constant, not a big-company problem. Secure-by-construction absorbs the baseline.
Small website attacks are not a big-company problem waiting to find you. Over one 30-day window at the edge, one small business we support saw 192,155 total requests, and 3,134 of those were attacks flagged and handled automatically. A newly exposed cloud server gets its first probe in about 52 seconds. That is the baseline, and every site sits on it from the moment it goes live.
Automated probing is the constant background condition of the modern web, not a rare event.
I find the psychology here fascinating, because "we are too small to be a target" feels true and is almost never accurate. It confuses a low public profile with low exposure. Attackers are not reading your homepage and deciding whether you are worth their time.
Why small website attacks are arithmetic, not attention
Most automated attacks are not personal. They are enumeration. Scanners walk the whole IPv4 address space, read public certificate transparency logs, and pull DNS records to build a list of everything that exists, then poke each entry with the same handful of known exploits.
You do not get chosen. You get counted. A Sophos honeypot study measured an average of 13 attack attempts per minute per honeypot, from servers that were advertising nothing and known to no one.
The traffic mix tells the same story. In 2024, bots made up 51% of all web traffic, with bad bots at 37%, according to the Imperva 2025 Bad Bot Report. More than a third of what hits an average site is automated and not there to help you. That is why the analytics you watch are only a floor, a point worth understanding on its own in what the server sees that your dashboard does not.
What the baseline actually looks like from the edge
Here is one anonymized example, offered as illustration rather than a trophy. For a single small local-services business over 30 days, the edge layer recorded 192,155 total requests. Of those, 3,134 were attacks, flagged and handled before they reached anything that mattered.
At the time of the assessment, the site passed 213 of 220 hardening checks, roughly 97%, with zero known critical vulnerabilities. Those checks were benchmarked against the technical controls in recognized frameworks including CIS, PCI-DSS, SOC 2, ISO 27001, NIST 800-53, CMMC, and HIPAA. Benchmarking a system against a framework's controls is not the same as a formal audit or certification against that standard, and it is not a claim of compliance with any of them.
At the edge, roughly one in sixty requests to this small site was an attack, quietly filtered.
None of that required a heroic response. It is what happens when patched dependencies, least privilege, no default credentials, TLS, and rate limiting are in place before launch. The attacks arrive on schedule; the engineering decides whether they land.
The reassuring part is that surviving the baseline is not exotic. Security is a byproduct of good engineering, not a separate product you buy afterward. The same choices that make a site fast, correct, and maintainable are the ones that make it hard to exploit.
There is a plainer reason we build this way. We help good people do good things, and a small business owner who serves their neighbors should not lose a weekend, or their customers' trust, to an automated script that never knew their name.
Patched dependencies close the exact holes the scanners test for. Least privilege limits what a single compromised component can reach. No default credentials removes the first thing every bot tries. TLS keeps data honest in transit, and rate limiting blunts brute force. We build this way by default, an approach I describe more fully in designing security into the architecture first and in why compliance is a side effect of how you build.
Secure by construction: the ordinary engineering choices that quietly absorb the baseline.
The benchmarks above are not interchangeable. Each answers a different question about how a system is built and run. A quick reference:
CIS Controls: a prioritized set of safeguards, a practical starting checklist for any organization.
PCI-DSS: the standard for anyone who handles payment card data.
SOC 2: an independent report on how a service provider manages customer data across security, availability, and privacy.
ISO 27001: the international standard for an information security management system.
NIST 800-53: a comprehensive catalog of security and privacy controls, widely used across US federal systems.
CMMC: the Department of Defense maturity model for contractors handling controlled information.
HIPAA: the US rules protecting health information.
You rarely need all of them. You do benefit from building as though someone might one day ask. That is the quiet advantage of teams like JDR Security Solutions, who run cloud health checks against exactly these standards, and it reflects how we approach engineering across the Kief Studio ecosystem.
Are small website attacks really automated rather than targeted?
Overwhelmingly, yes. Most probing comes from scanners that enumerate the entire internet and test every host for the same known weaknesses. You are counted in a list, not singled out, which is why even a brand new site with no visitors starts seeing traffic within minutes.
If my site is small and unknown, am I actually at risk?
Low profile does not mean low exposure. The same attacks reach every public site, and smaller organizations often feel the consequences more sharply. Verizon found ransomware or extortion in 88% of breaches at small and midsize businesses.
What is the single most effective thing to do?
Keep dependencies patched. Most automated attacks target known vulnerabilities that already have fixes available, so staying current closes the doors the scanners are checking. Pair that with removing default credentials and enabling TLS.
What does "secure by construction" mean in practice?
It means the engineering choices that make a site good also make it resilient: patched dependencies, least privilege, no default credentials, TLS, and rate limiting, all in place before launch. Security becomes a property of how the system is built rather than a layer added later.
How do you know a site is handling the baseline well?
Measure at the edge, where every request is visible, and benchmark against recognized frameworks. In the anonymized example here, that meant passing 213 of 220 hardening checks at the time of assessment, with zero known critical vulnerabilities, while attacks were flagged and handled continuously.
Nearly a third of breaches in 2025 involved a third party, double the year before. The sub-processor problem means every SaaS tool hands your data to its vendors' vendors. Third-party risk and data governance are one problem.
Non-compliance costs $14.82 million on average versus $5.47 million to maintain compliance, a 2.71x gap. Compliance engineering means building systems where evidence generates itself, not assembling it from memory before each audit.
Sonatype counted 1.23 million malicious packages. Your lockfile security posture determines whether those packages reach production or stop at the gate. The dependency layer is the attack surface now.