How to Protect Your SaaS from API Abuse and Scraping

How to Protect Your SaaS from API Abuse and Scraping

Your API is the most direct path to your product's data. It is also the most commonly abused one. API abuse and scraping can drain your infrastructure costs, expose user data, hand competitors a live feed of your product content, and degrade performance for legitimate users — all without triggering the alarms that catch more traditional attacks.

This guide covers how to identify API abuse and scraping, and the specific controls that stop it at each layer.

Understanding the Two Threat Types

API abuse covers a range of behaviours: automated account creation to take advantage of free tiers, credential stuffing attacks against your authentication endpoints, excessive API calls that exhaust rate limits or inflate your infrastructure costs, and automated exploitation of business logic (taking advantage of trial credits, submitting fraudulent transactions at high volume, or manipulating pricing mechanisms).

Scraping is the automated extraction of content from your product — your product catalogue, user-generated content, pricing, data feeds, or any valuable content that represents your product's value proposition. Scrapers consume your bandwidth and compute, copy your content, may violate your terms of service, and in some cases expose user data they were not supposed to be able to access.

Both abuse types share common characteristics: they come from automated clients rather than human users, they operate at volumes or patterns that human use would not produce, and they often attempt to evade the controls you have in place.

Layer 1: Authentication and Identity Controls

The weakest form of API protection is no authentication. Any API endpoint that returns valuable data without requiring authentication will be scraped. This is elementary and yet remains common.

For authenticated endpoints, the controls:

Rate limiting per identity, not just per IP. IP-based rate limiting is easily bypassed using rotating proxies. Rate limit per authenticated user token or API key. Define limits that legitimate usage stays comfortably within, and that automated abuse would hit within seconds or minutes.

Credential stuffing protection at login endpoints. Login endpoints are the primary target for credential stuffing attacks — automated attempts to log in using leaked username/password combinations from other breaches. Controls: CAPTCHA on login failures, exponential backoff on repeated failures, detection of concurrent login attempts from different IPs using the same account, and alerting on anomalous login patterns.

API key lifecycle management. API keys should be scoped (limited to specific permissions), rotatable, and revocable. A compromised API key with unlimited scope and no way to revoke it is a permanent vulnerability. Track which keys have been issued, monitor their usage patterns, and revoke automatically when anomalous patterns are detected.

Device fingerprinting and session analysis. For web-based products, device fingerprinting can identify automated clients even when they rotate IPs and change user agents. Tools like Fingerprint.js (open source) or commercial solutions like DataDome provide this.

Layer 2: Rate Limiting and Throttling

Rate limiting is necessary but often implemented too simply. Scraping tools are designed to work around basic rate limits.

Tiered rate limits that reflect legitimate use patterns. A user who makes 1,000 API calls in a second is not a legitimate user. A user who makes 100 calls per minute at perfectly regular intervals is also suspicious — human browsing produces irregular patterns. Implement rate limits that account for both volume and pattern.

Rate limits on write endpoints and state-changing operations. Heavy traffic on read endpoints is often scraping. Heavy traffic on write endpoints is often fraud: account creation, checkout, form submission. Different limits apply. Account creation without CAPTCHA or proof-of-work at any meaningful rate is an open door for fraudulent account farming.

Progressive penalties rather than hard cutoffs. Hard cutoffs (after X requests, you receive a 429 error for Y minutes) are easy to work around by staying just below the limit. Progressive throttling — where response times slow down as usage approaches limits, before hard limiting kicks in — is harder for automation to adapt to.

Cost-aware rate limiting. Some API calls are more expensive than others. An AI-powered search request that queries a large language model costs you 100x what a simple database read costs. Rate limiting by cost, not just count, prevents abuse that targets your most expensive operations.

Layer 3: Traffic Analysis and Anomaly Detection

Rate limits stop the most obvious abuse. Traffic analysis catches the more sophisticated attempts.

Request pattern analysis. Human users access your product with irregular patterns: time of day skewed toward business hours, gaps in activity, varied request types reflecting real browsing behaviour. Automated clients produce regular patterns: requests at consistent intervals, systematic coverage of your content (every product ID in order), uniform user agent strings, or specific sequences that reflect a crawling strategy.

IP reputation and proxy detection. Commercial data centre IP ranges, known proxy providers, and IP addresses that appear on threat intelligence feeds are significantly more likely to be sources of abuse. Services like IPInfo or MaxMind provide real-time IP data for enriching access logs with abuse probability signals.

Honeypot endpoints. Create API endpoints or content elements that are invisible to human users (hidden in the page DOM in a way that browsers do not render but crawlers do index). Any request to these endpoints indicates automation. Immediately flag and investigate any account or IP that touches them.

Unusual data access patterns. Legitimate users access a limited, context-driven subset of your content. A user who systematically requests every item in your product catalogue is scraping. Monitoring for systematic access — ordered IDs, complete coverage of categories, or access to items the user has no context to be viewing — surfaces scraping activity.

Layer 4: API Gateway and Infrastructure Controls

A dedicated API gateway. Moving API traffic through a gateway (AWS API Gateway, Kong, Apigee) provides centralised rate limiting, authentication enforcement, request logging, and integration with web application firewalls. It also provides a centralised point to add controls without changing application code.

Web Application Firewall (WAF). A WAF inspects incoming traffic for known attack patterns and blocks them before they reach your application. Modern WAFs have rulesets specifically for API abuse, OWASP Top 10 vulnerabilities, and bot detection. Commercial options (Cloudflare WAF, AWS WAF, Fastly) provide managed rulesets that are updated as new attack patterns emerge.

Bot management solutions. Enterprise bot management solutions (Cloudflare Bot Management, DataDome, PerimeterX) use machine learning to distinguish human from automated traffic in real time. They handle the full spectrum from obvious bots to sophisticated headless browsers that mimic human behaviour.

HTTPS with TLS certificate pinning for mobile clients. Man-in-the-middle attacks that intercept your API traffic enable reverse engineering. Certificate pinning makes this significantly harder for mobile clients.

Layer 5: Business Logic and Legal Controls

Technical controls reduce abuse but do not eliminate it. Business logic controls and legal mechanisms provide additional deterrence and recourse.

Terms of service that explicitly prohibit scraping. Scraping in violation of terms of service is the basis for legal action in many jurisdictions. Your ToS should explicitly prohibit automated access and commercial use of scraped data.

Account verification requirements. Email verification, phone number verification, payment method verification, or identity verification for high-trust features all raise the cost of creating accounts for abuse. Free tiers without verification are invitations for automated account farming.

Robots.txt. Not a technical control — robots.txt is honoured by well-behaved crawlers and ignored by scrapers. But it establishes the record that you have communicated that scraping is not permitted, which is relevant in legal contexts.

Monitoring and response. Define what you do when abuse is detected: automatic account suspension, manual review, reporting to hosting providers, or legal action. Without a defined response, detection is academic.

The OWASP Top 10 guide covers the specific application vulnerabilities that API abuse often exploits. The API security best practices guide covers the authentication and authorisation controls that form the foundation of API protection.

For SaaS businesses facing active scraping or API abuse problems, or looking to build protection into a new product from the start, our cybersecurity team assesses your current exposure and designs the right control architecture for your scale and risk profile. Contact us to discuss what you are dealing with.