Every website we host sees traffic that was never meant for a human audience. Scanners looking for exposed admin panels, credential stuffing against login forms, bots probing for an unpatched plugin. This has always been part of running anything on the internet. What has changed is the volume and the sophistication.
Writing an attack script used to take time and expertise. It is now something a person with no security background can assemble in an afternoon with an AI assistant. The cost of trying a thousand sites has collapsed, so attackers no longer bother choosing targets carefully. They sweep everything and come back to whatever answers.
If you run a small business website, an online store, or an API behind a mobile app, this affects you. Not because anyone singled you out, but because nobody is singling anyone out any more.
The mistake: treating security as an application problem
The common approach is to build the application, deploy it, and then think about hardening. By then, the server is already answering every request that arrives, from anyone, anywhere. Your application code becomes the only thing standing between an attacker and your database.
That is a lot of weight for application code to carry. A single missed input validation, one dependency with a known vulnerability, one forgotten debug endpoint, and the request that found it has already reached the part of your system that can do damage.
The better approach is to stop as much as possible before it ever reaches your application. Fewer requests arriving means fewer chances to get something wrong.
Put a proxy in front of everything
The first thing we do on every project is place the site behind a proxy such as Cloudflare, so that the public DNS record points at the proxy rather than at the server. Visitors connect to the proxy, and the proxy connects to your origin.
This single change does more than most people expect:
- Your server address stops being public. An attacker who cannot find your origin cannot attack it directly, and has to come through the front door where your rules apply.
- Known bad traffic is dropped before it costs you anything. The proxy maintains reputation data across an enormous number of sites and blocks traffic that has already misbehaved elsewhere.
- Volumetric attacks are absorbed away from your infrastructure. A flood that would overwhelm a single server is spread across a global network instead.
- TLS is terminated properly and certificates renew without anyone remembering to do it.
Once traffic is flowing through the proxy, the origin should be configured to accept connections only from it. If someone discovers the server address later, the server still refuses to talk to them.
Restrict the pages that do not need the public
Most applications have parts that no member of the public will ever legitimately visit. Admin dashboards, staff tools, internal reporting, deployment hooks. These are also the parts an attacker most wants to reach.
There is rarely a good reason to leave them open to the entire internet. An allowed IP list on administrative paths means a request from anywhere else is rejected before authentication is even attempted. Your login page cannot be brute forced by someone who cannot load it.
The usual objection is that staff work from home, from clients, from airports. That is fair, and the answer is not to abandon the control. Office ranges and a VPN endpoint cover most teams comfortably, and the inconvenience is small measured against leaving an admin login exposed to continuous automated guessing.
Block the countries you do not serve
A dental clinic in British Columbia does not need to accept administrative traffic from every country on earth. Neither does a regional logistics company or a local professional services firm.
Country-level rules at the web application firewall are a blunt instrument, which is exactly why they are useful. If your customers are in Canada and the United States, a rule that restricts sensitive paths to those countries eliminates a large share of automated traffic in one step, without any analysis of what that traffic was trying to do.
This needs thought rather than enthusiasm. Public marketing pages usually stay open, because customers travel and search engines crawl from everywhere. The restrictions belong on the paths that matter: administration, authentication, internal APIs.
Rate limiting is not optional any more
Rate limiting caps how many requests a single source can make in a given period. It is the control that turns most automated attacks from a real threat into background noise.
Credential stuffing depends on making thousands of login attempts. Scrapers depend on walking your entire catalogue quickly. API abuse depends on calling an expensive endpoint far more often than any real user would. All of them break when the request rate is capped.
We apply different limits to different paths, because the right number depends on what the endpoint does:
- Login and password reset: a handful of attempts per minute from one source, because no real person needs more.
- Search and listing endpoints: generous enough for browsing, tight enough that nobody copies the whole database.
- Anything that sends an email or SMS: strict, because these cost real money and are attractive to abuse.
- Static pages: usually left alone, since they are cheap to serve and cached anyway.
A well-set limit is invisible to your customers and immediately obvious to a bot.
Why the edge matters more than it used to
None of these controls are new. What changed is the economics on the other side. When attacks were manual, obscurity offered some protection, because nobody had a reason to look at a small business site. When attacks are automated and generated at near zero cost, every site is looked at, continuously.
The edge is where that volume gets filtered cheaply. By the time a request reaches your application, it should already have passed through a proxy that knows the sender has no history of abuse, a firewall rule that confirms it came from a country you serve, and a rate limit that proves it is not hammering you. Everything that follows is a smaller, more manageable problem.
Where this fits
Edge protection is the first layer, not the whole answer. A request that passes every check above still reaches an application running on a server, talking to a database, deployed by some process, with credentials somewhere. Each of those is its own opportunity to get it right or wrong.
In the next article in this series we look at that layer: how to structure AWS infrastructure so that even a successful application breach has nowhere useful to go. Private networking, databases with no public route, and deployments that use no long-lived keys at all.
If you are unsure what is currently exposed on your own setup, that is a reasonable thing to want checked. Logic Providers reviews infrastructure as part of our consulting work, and we are happy to talk it through.
