To protect a SaaS from attacks without migrating the application or rewriting code, put Azion in front of the app. Traffic goes through the Azion Firewall first, with WAF, Bot Manager, and rate limiting, and whatever the rules block never reaches your server, which stays where it is.
The scenario usually looks like this: the SaaS grew fast, often with code written with help from AI, and suddenly there is scraping, mass login attempts, and intrusion attempts. There is no time or budget to fix it the right way, and the security team, when there is one, is the developer.
Much of that work can go to a coding agent, such as Claude Code, which uses the Azion MCP servers to write the protection setup for the application that is already live, while you review every change before it reaches production.
How do you know if your SaaS is under attack?
The most common signs are traffic spikes on specific routes, thousands of failed logins, and strange parameters in URLs.
The example here is a fictional B2B ordering SaaS for retail, where store owners browse a catalog with negotiated prices and place orders with distributors. The app answers at app.yoursaas.com, runs on a server in some cloud reachable at origin.yoursaas.com, and nobody wants to touch it right now.
In the table, each sign appears with the attack it usually points to and the protection that responds to it. The routes are examples; every app organizes its own.
Sign (example) | What it usually is | Protection on Azion |
Request spikes on | Price scraping by competitors | Bot Manager and rate limiting per IP |
Thousands of failed logins on | Credential stuffing with leaked passwords | Bot Manager and rate limiting per IP |
Strange parameters in URLs, such as | SQL injection and XSS attempts | WAF |
Slow or unavailable server during the attack | DDoS | DDoS Protection, always on |
How do you protect a SaaS and its APIs without migrating the application?
By putting Azion in front of it as a proxy. The application stays on today’s server, with the same code and the same database; what changes is the path traffic takes, which now reaches Azion first, goes through the Firewall, and only then moves on to the server. Whatever a rule blocks never reaches the application.
In the Firewall, three controls do the work. Web Application Firewall (WAF) inspects every HTTP request and blocks attack patterns such as SQL injection and XSS. Rate limiting sets how many requests a single IP can make in a given interval. And Bot Manager scores every request to separate human browsing from automation, such as scraping and credential stuffing.
The snippets below are illustrative and show only the parts that change in this scenario; the full azion.config.ts also declares the application that uses the connector and the domain’s workload. The WAF comes in another way, explained right after the code. In the configuration, the current server becomes a connector, which tells Azion where to forward traffic:
connectors: [{ name: 'current-server', type: 'http', attributes: { addresses: [{ address: 'origin.yoursaas.com' }], connectionOptions: { transportPolicy: 'force_https' }, modules: { loadBalancer: { enabled: false, config: null }, originShield: { enabled: false, config: null }, }, },}],Outside the configuration file, two things change. The first is DNS: app.yoursaas.com now points to Azion, which can also issue the domain’s TLS certificate with Let’s Encrypt as soon as DNS points there.
The second is the origin, which should accept only traffic coming from Azion, so nobody can bypass protection by calling the server directly by IP. To do that, use Origin Shield: turn on the connector’s originShield module, which is off in the snippet above, and Origin IP ACL, then configure the origin’s firewall to accept only the list of IPs that Azion publishes.
How does Claude Code set up WAF, Bot Manager, and rate limiting through the Azion MCP?
The coding agent, Claude Code in this case, connects to the Azion MCP servers. Through the documentation server, which is read-only, it looks up the documentation, the CLI commands, and the API reference, and writes the policy in azion.config.ts. What applies the configuration to the account is azion deploy. The request can be as simple as this:
“Put Azion in front of my app, which answers at app.yoursaas.com and runs on the server origin.yoursaas.com. Apply the WAF in observation mode on all routes, rate limiting per IP on login and the catalog, and Bot Manager Lite on both routes, logging only, without blocking. Open a pull request with the change.”
The result is a Firewall like this one, with the Bot Manager Lite instance and the rules that trigger it:
firewall: [{ name: 'saas-firewall', functions: true, waf: true, functionsInstances: [{ name: 'bot-manager-lite', ref: 12345, // ID of the function installed from Azion Marketplace in your account args: { action: 'allow', threshold: 30 }, // logs only, does not block }], rules: [ { name: 'bot-manager-login-and-catalog', criteria: [ { variable: '${request_uri}', conditional: 'if', operator: 'starts_with', argument: '/login' }, { variable: '${request_uri}', conditional: 'or', operator: 'starts_with', argument: '/api/catalog' }, ], behaviors: [{ type: 'run_function', attributes: { value: 'bot-manager-lite' } }], // points to the instance above }, { name: 'rate-limit-catalog', criteria: [{ variable: '${request_uri}', conditional: 'if', operator: 'starts_with', argument: '/api/catalog' }], behaviors: [{ type: 'set_rate_limit', attributes: { type: 'second', limitBy: 'client_ip', averageRateLimit: '1', maximumBurstSize: '10' } }], }, { name: 'rate-limit-login', criteria: [{ variable: '${request_uri}', conditional: 'if', operator: 'starts_with', argument: '/login' }], behaviors: [{ type: 'set_rate_limit', attributes: { type: 'second', limitBy: 'client_ip', averageRateLimit: '1', maximumBurstSize: '5' } }], }, ],}],Bot Manager Lite, installed from Azion Marketplace and run as a function in the Firewall, scores every request on signals such as a missing user agent, missing headers a real browser would send, and a session cookie that doesn’t check out. When the score reaches the threshold, it applies the configured action. Because it doesn’t rely on the IP alone, it helps identify bots that switch IPs on every attempt, which per-IP rate limiting can’t do. The full version, Bot Manager, adds machine learning and Reputation Intelligence.
The limits are a starting point, to be tuned with real traffic. On the catalog, one request per second per IP, with a burst of 10, covers a store owner browsing and makes scraping from a handful of IPs impractical. On login, one attempt per second, with a burst of 5, is enough for someone who mistyped a password and slows down attacks from a single IP. Counting happens in each data center: excess requests are queued, and whatever goes past the burst gets status 429.
The WAF stays out of this file: azion deploy doesn’t create the WAF from azion.config, and the rule that attaches the WAF to the Firewall uses its numeric ID and the logging mode. So create both with the Azion CLI, using azion create waf and azion create firewall-rule, and tune sensitivity by threat family in the WAF itself. The JSON files for those commands can live in the same repository and go through the same pull request.
The agent proposes, but the team approves. When the main branch is protected and azion deploy only runs after the merge, every rule arrives as a pull request with the full diff, and none reaches production without review.
This flow is covered in more detail in The agent that writes your code also suggests your security policy and in Bringing application security into the deployment process.
How do you protect the SaaS without blocking real customers?
By starting in observation mode. With the app already in production, the biggest risk is turning away a real customer, so the WAF in Logging mode and Bot Manager Lite with the allow action only log the requests that would be blocked. Rate limiting is the exception, because it already blocks excess traffic from the first deploy. If several users from the same customer share one IP, as happens on corporate networks, start with looser limits.
In Real-Time Events, the HTTP Requests data source shows, for each request, fields such as wafMatch, with the violation and the snippet that triggered the rule, and wafScore, with the score by threat family. With Debug Rules turned on in the Firewall, which is off by default, the event also shows which rules ran; turn it on in the Console after each deploy, because azion deploy saves the Firewall with this option off. Bot Manager Lite records live in the Functions Console data source, with the score and the rules each request triggered. Events are available for 7 days, and Data Stream exports them to external systems, feeding SIEMs, data lakes, and analytics tools such as Splunk, Datadog, and BigQuery.
After a few days of real traffic, you handle the false positives and ask the agent to switch to blocking mode, in another pull request. If someone asks what was blocked and why, the events show the answer; to keep that history beyond 7 days, export it with Data Stream.
Steps to protect a SaaS in production with Azion
- Connect the coding agent, such as Claude Code, to the Azion MCP servers with a personal token.
- Ask for the configuration: the connector for the current server, rate limiting on login and the catalog, and Bot Manager Lite with the
allowaction inazion.config.ts, plus the Azion CLI commands that create the WAF and its rule inloggingmode. - Review the pull request with
azion.config.tsand approve the change. - With the Azion CLI authenticated, run
azion deploy, create the WAF and its rule in the Firewall, and point the app’s domain to Azion in DNS. - Issue the domain’s TLS certificate with Let’s Encrypt.
- Restrict the origin to traffic coming from Azion, with Origin Shield and the origin’s firewall.
- Monitor Real-Time Events for a few days and handle the false positives.
- Ask the agent to switch to blocking mode, in a new pull request.
How HeroSpark cut fraud and attack incidents by 99.5%
Without the agent flow described here, but with the same protections, HeroSpark, a digital education SaaS platform with its own payments solution, HeroPay, faced fraud and attacks that consumed its technical team. With Azion’s WAF, Bot Manager, and DDoS Protection, it cut fraud and attack incidents by 99.5%. And with Azion’s Security Response Team (SRT) automating detection and response, it gave the team back more than 200 hours of manual work per month.
Security and governance for the SaaS that is already live
Protecting a SaaS under attack doesn’t have to wait for a replatform or for hiring a security team. With Azion in front of the application, WAF, Bot Manager, rate limiting, and DDoS Protection take effect without changing a line of the app’s code, and every blocking decision is recorded in Real-Time Events.
The protections run on the same platform, on Azion’s distributed infrastructure, and blocking happens in the data center that receives the request, far from your server. And because the policy lives in a versioned file reviewed through pull requests, the developer who handles security today gets a process that keeps working as the team grows. If the SaaS is still to be built, the full path is in How to structure an AI SaaS with security on Azion.
Is your SaaS under attack right now? Talk to an Azion expert to protect your app without migrating, or create a free account to test the setup first.
Frequently asked questions
Do I need to change the application’s code to use a WAF? No. You declare the security policy in a configuration file, point the app’s domain to Azion in DNS, and, so nobody can bypass protection, restrict the origin to traffic coming from Azion.
How do I block scraping on my SaaS? By combining Bot Manager Lite, which scores every request on signals such as headers and session cookies, not just the IP, with rate limiting per IP on the most targeted routes, such as the product catalog.
Can Bot Manager Lite block real customers? It can, if it starts out blocking. That’s why it starts in observation mode, with the allow action, which only logs, and blocking comes after a few days of real traffic and after tuning the false positives.
What is credential stuffing? It’s an attack in which bots test, at scale, e-mail and password combinations leaked from other services, betting that some users reuse the same password. On a SaaS, it shows up as thousands of failed logins in a short time.
What is price scraping and why is it a problem? Scraping is the automated collection of data from a website or API by bots. On a B2B SaaS, it usually targets prices and catalogs, which can end up with competitors, and it also overloads the server.
Can a coding agent set up my app’s security on its own? It can write the entire configuration, but approval should stay with the team. Ask the agent to deliver every change as a pull request to the configuration file, instead of changing the account directly through the MCP servers, and only run the deploy after the merge.
Does it work if my SaaS runs on AWS, Azure, or Google Cloud? Yes. The application stays in the cloud where it already is, or on your own servers; only the domain starts pointing to Azion, which filters requests before forwarding them to the origin server.
How do I protect login against brute force and credential stuffing? With rate limiting per IP on the login route and Bot Manager scoring every attempt, which helps against bots that switch IPs. In the application, MFA and leaked-password checks complete the protection. The Financial API Security post shows the same combination applied to APIs that handle sensitive data.
