DEV Community

Cover image for Solved: Large Competitor Just Ordered My Products – What To Do?
Darian Vance
Darian Vance

Posted on • Originally published at wp.me

Solved: Large Competitor Just Ordered My Products – What To Do?

🚀 Executive Summary

TL;DR: When competitors order products or scrape services for corporate espionage, businesses must implement a multi-layered defense. Solutions range from immediate IP bans and automated behavioral analysis with tools like Fail2ban or WAFs, to ‘nuclear’ ASN/Geo-blocking for persistent adversaries.

🎯 Key Takeaways

  • Implement quick IP bans or subnet denials using web server configurations (e.g., Nginx deny directive) for immediate, albeit temporary, blocking of identified competitor IP addresses.
  • Deploy automated behavioral analysis systems like Fail2ban for self-hosted environments or Web Application Firewalls (WAFs) in cloud platforms to detect and block traffic based on suspicious patterns, such as excessive requests or failed logins.
  • Utilize ASN/Geo-blocking as a ‘nuclear’ option to block entire corporate networks or geographical regions at the firewall or CDN level, effective against persistent adversaries identified by their Autonomous System Number.

When a competitor starts sniffing around your services, you can’t just ignore it. This guide covers how to identify and block unwanted traffic, from quick IP bans to robust, automated behavioral analysis.

So, Your Competitor Just Ordered Your Product. Here’s How We Handle Corporate Espionage.

I remember a gig back around 2016. We had just launched a slick new API for our SaaS product. We were a small, scrappy team, and we were proud of our documentation – it was clean, interactive, and way better than the incumbent’s. Two weeks later, our biggest competitor, a behemoth in the space, rolled out a “brand new” API doc portal. It was a pixel-for-pixel, word-for-word clone of ours. They’d just scraped the entire thing. We found their office IP addresses all over our Nginx logs, hitting every single page in sequence. It was infuriating, but it was also a lesson: if it’s on the public internet, assume your competition is watching.

That feeling—a mix of flattery and fury—is exactly what I saw in a recent Reddit thread. A small business owner noticed their main competitor making test orders, likely to reverse-engineer their product, fulfillment process, or pricing. It’s a classic move. So, let’s talk about what’s really happening and what you, as the engineer on the ground, can actually do about it.

The “Why”: It’s Not a Bug, It’s a Feature (of the Internet)

First, let’s get one thing straight. The root cause here isn’t a technical flaw in your system. It’s the nature of public-facing services. Your website, your API, your storefront—they’re designed to be accessible. The challenge isn’t preventing access; it’s preventing unwanted access and abuse. They aren’t “hacking” you; they’re just using your front door like any other customer. Our job is to become a smarter bouncer.

The goal is to move from a simple “allow all” posture to one that intelligently identifies and mitigates traffic that looks less like a customer and more like a corporate spy with a web scraper.

The Fixes: From Duct Tape to Fort Knox

We have a few tools in our belt, ranging from a quick fix to a more permanent, architectural solution. Let’s break them down.

Solution 1: The Quick and Dirty IP Ban (The Duct Tape)

This is the first thing everyone thinks of, and for good reason. It’s fast, simple, and provides immediate satisfaction. You’ve found their corporate IP address in your logs. Now, you block it at the edge.

If you’re running your own web server like Nginx, it’s as simple as adding a few lines to your configuration. You find the offender’s IP (let’s say it’s 203.0.113.42) in your logs on prod-web-us-east-01 and then you drop the hammer.

# Add this inside your http or server block in nginx.conf

# Block specific malicious or competitor IP addresses
deny 203.0.113.42;
deny 198.51.100.10;

# Deny an entire subnet if they get tricky
deny 192.0.2.0/24;

# ... the rest of your server configuration follows
# location / { ... }
Enter fullscreen mode Exit fullscreen mode

You reload Nginx, and poof, they’re gone. They’ll just get a “403 Forbidden” error.

Warning: This is a temporary solution, a digital restraining order. They will come back using a different IP, a VPN, or a cloud proxy. This is a game of whack-a-mole, but sometimes, you just need to stop the bleeding right now.

Solution 2: The Permanent Sentry (Behavioral Analysis)

Blocking a static IP is reactive. A much stronger, long-term solution is to block based on behavior. A real customer doesn’t request 500 pages a second. A real customer doesn’t try to access /wp-admin.php ten times with different passwords. This is where rate-limiting and automated banning tools come in.

On-Prem / Self-Hosted: Fail2ban

If you’re managing your own servers, Fail2ban is your best friend. It monitors log files for patterns (like too many 404s, failed logins, or aggressive scraping) and automatically updates firewall rules to block the offending IPs for a set period. It’s like an automated version of the quick fix.

A simple “jail” for aggressive scrapers in jail.local might look like this:

[nginx-badbots]
enabled  = true
port     = http,https
filter   = nginx-badbots
logpath  = /var/log/nginx/access.log
maxretry = 100
findtime = 60
bantime  = 86400
Enter fullscreen mode Exit fullscreen mode

In this example, if an IP hits pages that your nginx-badbots filter flags (e.g., scraping patterns) more than 100 times in 60 seconds, they get banned for a full day (86400 seconds). This is much more robust.

In the Cloud: The WAF

If you’re on AWS, Azure, or GCP, you should be using their Web Application Firewall (WAF) services. These are managed services that let you build sophisticated rules. You can create rate-based rules that automatically block an IP if it exceeds, say, 1,000 requests in a 5-minute period. This is the “set it and forget it” approach that scales beautifully and is my go-to recommendation for any serious application.

Pros of Behavioral Blocking Cons of Behavioral Blocking
* Automated and proactive. * Catches attackers even if they switch IPs. * Harder to circumvent than a simple IP ban. * Protects against a wider range of abuse (DDoS, scraping, etc). * Requires more careful configuration to avoid blocking legitimate users (e.g., a corporate office behind a single NAT). * Managed WAF services have a cost associated with them.

Solution 3: The ‘Nuclear’ Option (ASN/Geo-Blocking)

Sometimes, the problem is bigger than a few IPs. If your competitor is a large corporation, they likely own their own block of IP addresses, registered under an Autonomous System Number (ASN). An ASN is essentially a network’s social security number. If you can identify their ASN, you can block their entire network at your firewall or CDN level.

You can find an IP’s ASN using a simple whois command or an online tool. If you discover their traffic is consistently coming from “AS7018 – AT&T Services, Inc.”, but you know they are a tech company hosted on AWS, you’ve found their corporate network. You can then use your cloud provider’s WAF or a service like Cloudflare to block all traffic originating from that ASN.

This is a very big hammer. You might block legitimate customers who happen to use the same ISP, or you might block their marketing team while the engineers just switch to a VPN. But if you have a known, persistent corporate adversary operating from their own network, this is a powerful and surprisingly effective way to shut the door.

Pro Tip: Don’t just block, monitor. Set up alerts in Grafana or your logging tool of choice for spikes in 403s from a specific IP block or region. This tells you when they are testing your defenses and trying to find a way around them. Seeing a bunch of failed requests from a new IP range right after you blocked their old one is confirmation that your strategy is working and annoying them. And sometimes, that’s the best we can hope for.

At the end of the day, you can’t stop a determined competitor. But you can make their life incredibly difficult, slow them down, and protect your hard work. Start with the IP ban for immediate relief, implement rate-limiting as your standard practice, and keep the ASN block in your back pocket for when you need to send a clear message.


Darian Vance

👉 Read the original article on TechResolve.blog


Support my work

If this article helped you, you can buy me a coffee:

👉 https://buymeacoffee.com/darianvance

Top comments (0)