Does the Vercel Firewall Actually Work? Reddit Asks — Here Are 96 Days of Logs
Every few weeks somebody asks a version of this question and appends "reddit" to it, hoping a real person will answer instead of a vendor.
They mostly don't get one. The results are security companies explaining why you need their product, and aggregator pages listing eleven tools nobody has used.
So here are ninety-six days of logs from a system I built and run. Every address in this post can be checked against a public third-party database, because I reported them there as it happened — before I knew I'd be writing this.
The short answer is yes. The longer and more useful answer is that the firewall was the last thing I did, not the first — and most of what it had to block was traffic the architecture had already made pointless.
cloud servers, in 39 days
that followed
with no public links
into the system
Two Halves That Never Touch
Nearly every business system is one thing: an application that serves the public and holds the data and runs the admin screens, all on one hostname. Everything an attacker wants is reachable from the same front door your customers use.
I don't build them that way.
One Application, One Door
- Public pages and admin screens on the same hostname
- Code executes on every request, by design
- A live database sits behind that code
- A login page anyone on earth can reach
- Must be simultaneously findable and hidden — impossible
Front Static, Back Hidden
- Araptus Highlander generates the public half ahead of time
- No login, no request-time execution, no reachable database
- Araptus Doon holds the application, off the index entirely
- Araptus Gateway is the only route between them
- Each half optimised for the opposite goal
The half everyone can find has nothing worth taking. The half worth taking, nobody is supposed to find.
The part people miss is that this is an SEO decision as much as a security one. The two halves have opposite goals, and one combined application cannot serve both. The public site is engineered to be crawled as completely as possible — everything indexable, everything fast, everything legible to a machine. The operations half is engineered to be crawled by nobody: disallowed in robots.txt, noindex on every layout, an X-Robots-Tag on the responses, rate limiting on the door.
You cannot tune one system to be maximally findable and maximally hidden at the same time. Split it in two and each half gets optimised properly — which is why the marketing site can chase rankings aggressively while the system holding the actual business data appears nowhere at all.
What Is Actually Being Measured
Be precise about the property, because vagueness is what makes data posts unfalsifiable.
The system is an Araptus Doon operations dashboard I run internally. It carries a noindex directive, it blocks crawlers, and it has no public inbound links. By every conventional measure it should be invisible. Nobody is looking for it, and nothing points at it.
Two independent records cover it. The first is the application's own security event log — 623 rows, spanning May to August 2026. The second is a public abuse database: reports I filed to AbuseIPDB as the events happened, which are third-party, timestamped, and beyond my ability to edit after the fact.
The second one matters more than the first. Anyone can look those addresses up.
Invisible Is Not the Same as Unreachable
In the 39 days before the change, that supposedly invisible system logged 375 security events — 9.6 per day. Of those, 238 came from rented cloud address space, across 18 distinct addresses. 62 were scanner path probes, from 23 distinct addresses. In total, 88 different addresses touched it.
Ownership lookups on the heaviest sources come back as infrastructure, not people:
Google LLC
The single heaviest source in the dataset, and the address that later triggered an automatic lockdown.
Amazon Technologies
Four of the top eight sources resolve to Amazon, most of them registered to a Northern Virginia data centre.
Google Cloud, Seoul
Region is irrelevant to the target. Scanning is cheap enough to rent capacity anywhere and sweep from it.
These are not compromised home routers. Somebody is paying a hyperscaler by the hour to scan the internet. That is the economics you are actually up against.
A Catalogue, Not a Campaign
The paths tell you nobody targeted this business. They were reading down a list — credential files, configuration files, and known holes in frameworks the system does not run:
/.git/config a repository's configuration
/.env /.env.local environment files, three variants
/.env.production
/config/.env.production and again, one directory down
/config/.aws/credentials cloud credentials, hopefully absent
/wp-login.php WordPress login
/wp-json/… a WordPress mail plugin's test route
/_ignition/execute-solution a PHP framework's debug endpoint
/actuator/auditevents a Java framework's monitoring route
/config.jsonThe system runs none of those frameworks. No WordPress. No PHP. No Java.
The clearest single artifact is one public abuse report filed in May 2026 against an address that requested four different credential paths in eight seconds. Not a person looking around. A script working through a menu.
The user agents are worth reading too. One claimed to be OS/2. One claimed a PowerPC Mac. One announced itself as a site-audit tool. Two were honest — an academic plagiarism crawler and a security vendor's research scanner. One arrived wearing an AI crawler's name while requesting a git config file, which is almost certainly a spoofed agent rather than the real thing.
The obvious assumption is that scanning volume tracks how well-known you are.
This system is unlisted, uncrawled and unlinked — and 23 distinct addresses still probed it in five weeks. Obscurity is not a control.
Why These Numbers Exist At All
Most businesses could not write this post about their own systems, and it isn't for lack of interest. They don't have the data, because nothing on their stack was built to record it. A default deployment tells you a request returned a 404. It doesn't tell you the same address tried eleven credential files in a row.
So the detection layer is built into Araptus Doon itself:
283 trap paths
207 general honeypot routes plus 76 WordPress-specific scanner paths. Requesting one is unambiguous — no legitimate visitor asks for a credentials file.
Five correlated signals
Honeypot hits, authentication floods, rate violations, route scanning and bot crawling — evaluated together over a rolling five-minute window rather than counted separately.
Thresholds that fire on shape
Five distinct addresses hitting honeypots. Fifteen authentication failures. Eight rate-limit violations. Three addresses scanning routes in concert. Or one address showing several signal types at once.
Progressive response
Rate-limit violations escalate in severity. Three of them gets the address blacklisted automatically, without anyone being awake.
Attack mode and outbound reporting
A system-wide lockdown the trip-wire can engage on its own, recording who enabled it and why — plus automatic reporting to a public abuse database, which is why the third-party record backing this post exists.
All of that sounds like infrastructure you build and never see fire. In June 2026, at 07:17 UTC, it fired.
One address — registered to Google LLC — tripped three different signals inside the five-minute window. The system logged it in its own words: multi-vector attack: honeypot, auth flood, bot crawl.
That was the busiest day in the entire dataset — 99 events, 92 of them from cloud addresses. The lockdown engaged without me touching anything. I read about it afterwards.
This is the part that isn't buyable off a shelf. A firewall tells you it blocked something. This tells me what kind of attack it was, from where, across which vectors, in one sentence — which is the difference between a wall and threat intelligence.
The Part I Did Not Expect
Then it stopped. In the 57 days that followed, cloud-address probe events: zero. Scanner path probes: zero.
The last cloud-range event was an Amazon-registered address probing an internal admin route in the small hours of a June morning. The last scanner probe, eighteen hours before that, was a request for a git config file. The last public abuse report I filed carries the same date.
Two records that don't talk to each other, agreeing on the same cutoff day.
Traffic didn't fall. Distinct addresses actually went up, from 88 to 112. Hostile traffic fell — to nothing — while real usage carried on.
What This Does Not Prove
Zero events is not zero attacks. A request blocked at the edge never reaches the application, so the application cannot log it. The correct reading is that nothing hostile reached the system for 57 days — not that the internet stopped trying.
One property, not a fleet. This is a single system in a single configuration. It is evidence, not a law.
I can tell you when it stopped, not exactly what stopped it. Application-level attack mode was also toggled three days before the traffic ends, and I don't have a timestamped record of the firewall change itself. What two independent systems agree on is the date. The firewall is the most likely cause, and I'm not going to dress that up as proof.
My own test traffic is excluded. Two honeypot events in July came from an internal request where address extraction returned null. That was me testing the traps, and it is not in any figure above.
A firewall is not a security strategy. It removed one very large, very automated category of traffic — and did nothing about DNS, hosting accounts, the build pipeline, third-party scripts, or anybody's password.
Why the Architecture Did the Heavy Lifting
Look again at what those scanners spent five weeks asking for: WordPress logins, a PHP debug endpoint, a Java monitoring route, environment files, git configs, cloud credentials.
Now look at where they were asking. Not the public website — the back half. The website is statically generated by Araptus Highlander; there is no login page to brute-force, no code running per request to exploit, and no database on the public internet to reach. A scanner can sweep it all day and find nothing on the other side of any of those paths.
So the entire five weeks of pressure landed on the one component that is dynamic — and that component was already unindexed, crawler-blocked, unlinked and on a separate deployment. The firewall was the last layer on the smallest surface, not the first line of defence.
Make the public half unattackable
Rather than defended. Nothing to exploit beats everything patched — and it can then be crawled as aggressively as you like.
Move the dynamic half out of the index
So it isn't in anyone's target list to begin with.
One narrow route between them
Araptus Gateway, so public forms work without exposing anything behind them.
Then put a firewall on what's left
Most stacks do only this step, on a system doing all four jobs at one address. That's why their firewall has so much more to stop.
The honest version of this post's headline:
The firewall worked, and it had an easy job — because by the time traffic reached it, there was almost nothing left to defend.
I build and operate the software my clients run their businesses on, which means when something is attacked, I'm the one reading the logs. I'd rather publish what those logs actually say than another page explaining why security matters.
If you want to check any of this, the addresses are in a public abuse database with timestamps I can't edit. That is the whole point of reporting them there.
The bottom line
A system nobody could find was still probed by 23 addresses in five weeks — and by none at all in the eight weeks after.
Obscurity isn't protection, and a firewall isn't architecture. Separate what's public from what's valuable, and there's far less left to block.
Sources & Method
- AbuseIPDB — public abuse reports filed during the measured window
- ARIN RDAP — address ownership lookups
- OWASP — Top Ten
- Araptus — Your Website Has No Database to Hack
Method. First-party security event log, 623 rows, May–August 2026. A "cloud probe event" is one whose source address falls in a major cloud provider's allocation. A "scanner path probe" is a request for a known credential, configuration or CMS path. The author's own test traffic is excluded. Internal route names have been generalised.
