Most security discoveries happen in labs.
Mine happened while procrastinating with Google AdSense.
I was just trying to preview how ads would look on my website. Instead, I stumbled into a loophole that lets anyone bypass Cloudflare's Under Attack Mode on any website.
Here's the kicker: It works because Google trusts everyone, and Cloudflare trusts Google.
The accidental discovery
Over a year ago, I was messing around with Google AdSense. If you've ever used it, you know they have this neat feature called "website ad experiments." It lets you preview how ads would look on your site without touching any code.
Pretty standard stuff, right?
But then I got curious. I opened up the browser's developer tools and started poking at the HTTP requests. That's when things got interesting.
The request was simple — Google would fetch your website, inject the ad preview, and show you the result. But here's what caught my eye: the domain parameter wasn't validated on the server side.
At all.
So I did what any curious person would do. I changed the domain in the POST request from my site to something else. Maybe a site behind Cloudflare's infamous "checking your browser" screen.
And it worked.
Google fetched the site. Cloudflare let it through. No challenges. No rate limits. Nothing.
I had just turned Google into my personal proxy server.
Why this works (and why it's Google's fault)
The magic happens because of a simple oversight: Google doesn't validate which domains you're allowed to preview.
When you send a request through AdSense's preview feature, Google's servers make the actual request to the target website. From Cloudflare's perspective, the visitor isn't you — it's Google.
And here's where it gets juicy: The requests come from IP address 66.249.88.36.
That IP? It's on Cloudflare's VIP list.
The whitelist that makes it all possible
Google publicly announces their IP ranges for services to whitelist. You can find them at https://gstatic.com/ipranges/goog.json.
The IP we're using (66.249.88.36) falls within the range 66.249.64.0/19. That's 8,190 IP addresses that Cloudflare automatically trusts.
Why? Because blocking Google would be suicide for most websites. No Google crawlers means no SEO. No SEO means no traffic. No traffic means no business.
So Cloudflare has to let Google through, always.
What the server sees
I tested this on my own domain to see what actually happens. Here's the difference:
Normal request from my browser:
- Origin IP: My actual IP address
- User Agent: My browser
- Gets challenged by Cloudflare
- Rate limited after too many requests
Request through Google's preview:
- Origin IP: 66.249.88.36 (Google)
- User Agent: Google's bot
- Sails right through
- No rate limits applied
The server behind Cloudflare has no idea the request originated from me. It thinks Google is just doing its thing.
The plot twist: It's surprisingly sophisticated
This isn't just a simple proxy. Google's preview system actually renders the entire page using what seems like Puppeteer (Google's headless Chrome tool).
It doesn't just fetch the HTML. It:
- Downloads all CSS files
- Grabs JavaScript files
- Loads fonts and images
- Executes the JavaScript
- Combines everything into a single response
You get back a dirty JSON blob with the fully rendered page inside. It's messy, but it's all there.
Why this bypass is both genius and useless
Before you get too excited, let me crush your dreams. This bypass has serious limitations:
1. GET requests only You can't POST data, submit forms, or do anything interactive. You're basically a tourist taking photos through a window.
2. No error responses If the server returns a 404 or 500 error, Google swallows it. You get nothing back. Zero visibility into what went wrong.
3. Limited rule bypassing This bypasses Cloudflare's global Under Attack Mode, but specific firewall rules might still catch you. If a site blocks all traffic except from specific countries, you're still out of luck.
4. It's meant for previews The response comes back as a jumbled mess of JSON and HTML. Parsing it for anything useful is a nightmare.
5. Google could fix this tomorrow All it takes is Google adding proper domain validation, and this whole thing disappears.
The bigger picture
This discovery highlights something important: Security often fails at the seams between services.
Google built a feature for legitimate use (ad previews). Cloudflare built protection assuming requests come directly from users. Neither considered how their systems would interact.
The result? An accidental bypass that's been sitting there for who knows how long.
Lessons from the loophole
1. Always validate on the server side Client-side validation is just a suggestion. If Google had checked whether users actually owned the domains they were previewing, this wouldn't exist.
2. Trust creates vulnerabilities Cloudflare has to trust Google. But that trust becomes a weakness when Google's systems can be manipulated.
3. Features become exploits Google AdSense preview wasn't designed as a proxy. But with a small tweak, that's exactly what it became.
4. Simple oversights have big implications One missing validation check created a bypass for one of the internet's biggest security providers.
Should you use this?
Honestly? No.
It's clever, but it's not practical. You can't do anything meaningful with GET requests only. You can't see errors. You can't interact with the site properly.
It's like having a key to every house, but you can only look through the mail slot.
Plus, using Google's infrastructure as an unauthorized proxy probably violates their terms of service. And they have very good lawyers.
The real value
This isn't about the bypass itself. It's about the mindset.
I found this by being curious about a mundane feature. By asking "what if I change this parameter?" By testing assumptions.
That's how real discoveries happen. Not in grand plans or sophisticated attacks. But in small moments of curiosity.
So next time you're using a service, poke around. Test the boundaries. Question the assumptions.
You might just find something interesting.
Even if it's beautifully useless.
The article based on this X post.
