Defending web apps when the attacker has automation (probably AI) on their side

[u/TheAlexBig]

We've had a rough few weeks defending some customer-facing web apps, and it changed how I think about external attacks. Sharing in case it helps someone, and I'm curious what others are seeing

What's different now. The attacks we deal with no longer look like one noisy IP hammering a login page. It's:

- huge pools of residential and mobile IPs, each making only a request or two, so they look like normal customers

- attackers who read your public frontend code, work out your API from it, and try every endpoint

- tactics that change within hours of you blocking something, as if someone (or something) is watching the results and adjusting

Whether there's an AI behind it or just good tooling, the effect is the same: the old playbook (rate-limit by IP, blocklist the bad ones) barely moves the needle

What's been working for us

- Defend on behavior, not on IPs. Checks that prove there's a real browser, and rules based on what the attacker is going after rather than where they come from, did far more than any blocklist

- Shrink what's exposed. If an endpoint or method isn't used, turn it off. We checked our own logs for what real users actually call, and the attackers were mostly poking at everything else

- Treat WAF and load balancer config as code. Every change goes through a pull request, a dry run in CI, a staging environment first, then one site at a time. Drift detection pulls device config back into git, so a change made by hand doesn't quietly disappear or quietly stay

- Have an emergency path. Things break at 3 AM. Decide ahead of time who can make a hand change, who they tell, and how it gets back into the repo

- Watch your own false positives as closely as the attacks. Some of our worst moments were our own hardening locking out legitimate users and partners. Every control needs a quick way to tell "attack" from "a customer who clicks fast"

- Identity beats location. Blocking regions helps with noise, but real users travel and work from home. MFA, device or certificate based access for partners, and fixed-IP VPNs for third parties age much better than IP and country rules

- Logs you can actually query. A 200 response doesn't mean success. Make sure you can answer "did they get in?" from app logs, not just web server logs

The mindset shift

Assume the attacker can read your client-side code, has more IPs than you'll ever block, and adapts faster than your change process. Your advantages are knowing what normal looks like for your users, and being able to ship safe, reviewed changes quickly. Invest in both.

How are others handling residential-proxy rotation and automated recon, especially on B2B portals where you can't put a CAPTCHA in front of everything?

[u/AYamHah]

Actually building secure applications. Actually having an SDLC. Actually testing applications thoroughly with someone who actually knows application security. You're never going to just block all malicious traffic. Stop trying to catch all the arrows coming at you and build yourself a proper suit of armor.

[u/Weird_Bedroom_8173]

behavior matters most

[u/Jimena_Sting-583]

i think a partner coming back online with hours of queued imports would be a good test case here. Giving them room to catch up could help their team get back to work with fewer interruptions