India’s Leading Domain & Web Hosting Provider
Support
Domain & Login
Blog
Web Application & API Protection: WAF, Bot and DDoS Defence
Web application protection is the layer in front of websites and APIs that filters attacks before they reach code: WAF rules for injection and exploits, bot management, rate limits, API schema checks and DDoS absorption. NTSPL designs and tunes this layer on AWS WAF, Azure Front Door and Cloud Armor for Indian marketplaces, portals and fintechs, measuring abuse blocked against genuine users affected.
Delivered on
In scope
Bots, Credential Stuffing and API Abuse: The Attacks That Cost Money
Most WAFs we inherit were switched on with a managed rule set in count mode and never touched again, or set to block and then hollowed out with exceptions after the first false positive stopped checkout. Meanwhile the attacks that actually cost money are not SQL injection; they are credential stuffing on login, scripted fake sign-ups farming referral coupons, scrapers copying prices every few minutes, and API calls that skip the mobile app entirely. Peak sale days and tender deadlines are when both abuse and genuine traffic surge together.
NTSPL treats the protection layer as a product with its own metrics. We baseline traffic, separate humans from automation using provider bot signals and client-side tokens, and write rules per route: strict on sign-up, login, OTP and coupon endpoints, lighter on catalogue pages. Managed rules move from count to block in stages with false-positive review. Origins are locked so traffic cannot bypass the edge, and runbooks cover attack-day tuning.
Traffic Patterns That Show Your WAF Is Not Doing Its Job
Signals you need Web Application Protection
- Login failure rates exceed 20% during peaks, a typical sign of credential stuffing
- Sign-ups or OTP requests spike 5-10x during promotions without matching orders
- Managed WAF rules have sat in count mode for months, or more than 15 rule exclusions exist
- Origin servers or App Services are reachable directly on public IPs, bypassing the WAF
- A DDoS or deadline-day surge has taken the site down in the past 12 months
When to choose something else
- The vulnerabilities are in your own code and need fixing at source; a WAF buys time but DevSecOps and vulnerability management fix the cause.
- Your concern is attacks between internal systems after an attacker is inside; that is Cloud Network Security.
Rule Sets, Bot Controls and Origin Lock-Down We Configure
Managed and custom rules
Tune OWASP core and provider-managed rule groups per application, staged from count to block with exclusions scoped to single fields, never whole rules.
Bot and fraud controls
Configure AWS WAF Bot Control, ATP and ACFP, Front Door bot manager rules or reCAPTCHA Enterprise with Cloud Armor, plus client-side tokens in web and mobile apps.
Rate limiting per route
Set rate limits by IP, session token, phone number hash or header for OTP, login, coupon and search endpoints, with different thresholds for sale days.
API protection
Validate request schemas, methods and payload sizes at the gateway, and block undocumented endpoints discovered from logs.
DDoS and origin lock
Enable Shield Advanced, Azure DDoS Protection or Cloud Armor Enterprise where justified, and restrict origins to accept only edge traffic.
Edge to Origin: Layered Request Filtering Design
Layered Edge Filtering for Web Apps and APIs
Requests pass DDoS absorption and CDN edge, then WAF managed rules, bot classification and route-specific rate limits before reaching an API gateway that validates schema. The origin accepts traffic only from the edge, and every decision is logged for tuning.
Select any component
Layered Edge Filtering for Web Apps and APIs: click any of its 8 components to see its role and the design choice NTSPL makes for it, or trace the 7-step primary path.
AWS WAF, Front Door WAF and Cloud Armor Capabilities Mapped
ATP checks login attempts against stolen-credential data, and ACFP scores sign-up attempts; both work best with the WAF JavaScript or mobile SDK integrated.
Front Door Premium is required for managed rule sets and bot protection; origins should use Private Link so App Service is never exposed directly.
Cloud Armor's preconfigured WAF rules use sensitivity levels; reCAPTCHA tokens can be evaluated directly in Cloud Armor rules for login and sign-up paths.
Route-Level Rules, Challenge Strategy and Block Thresholds
Global rules or per-route policy
Apply managed rules globally but write bot and rate rules per route. A blanket 2,000 requests per five minutes per IP blocks offices behind carrier-grade NAT, common on Indian mobile networks, while missing distributed bots. Key OTP limits on hashed phone numbers, login on username and IP pairs, and search on session token.
Challenge or block
Block only high-confidence automation such as known bad signatures and failed tokens. Use silent challenges or CAPTCHA for medium-confidence traffic on sign-up and login, and never on payment confirmation. Keep CAPTCHA solve rates visible: if more than 3-5% of challenged sessions come from logged-in repeat customers, the threshold is too aggressive.
When to buy DDoS protection plans
Basic DDoS protection on every edge service covers common network floods. Buy Shield Advanced, Azure DDoS Network Protection or Cloud Armor Enterprise when an hour of downtime costs more than the annual plan, when you need cost protection for attack-driven scaling, or when regulators expect evidence of DDoS readiness. Most single-app SMEs do not need them.
Moving managed rules to block
Run each new rule group in count mode for at least 7 days including a peak day. Review every rule with matches above 0.1% of legitimate requests, add field-scoped exclusions, then block. Promote one rule group at a time with a rollback rule ready. Expect 3-8 exclusions per mature application.
Count Mode to Block Mode Without Losing Real Customers
Traffic baseline and route inventory
Analyse a month of edge logs to list routes, bot share, top abusers and current WAF matches.
Origin lock and logging
Restrict origins to edge traffic and stream full WAF logs to an analytics store.
Bot and route rules in count mode
Integrate client tokens, define route limits and observe through at least one promotion.
Staged enforcement
Move rule groups and bot rules to block or challenge one at a time with false-positive review.
Attack-day readiness
Pre-approve emergency rules, rehearse a simulated surge and hand over the tuning cadence.
What you receive
Abuse Blocked Versus Genuine Users Challenged
| KPI | Typical target |
|---|---|
| Automated sign-ups and OTP requests blocked | 85-95% of identified abuse |
| Genuine sessions challenged | Under 1% of logged-in users |
| Requests reaching origin outside the edge | Zero |
| Time to deploy an emergency rule during an attack | Under 15 minutes |
False Positives, Origin Bypass and Attack-Day Pitfalls
| Risk | How NTSPL prevents it |
|---|---|
| A blocking rule silently stops checkout for one browser or app version | Synthetic journeys for checkout and login run every five minutes against production through the WAF. |
| Attackers bypass the WAF by hitting origin IPs | Origins accept only edge prefix lists, verified headers or Private Link, tested from outside. |
| Rate limits block corporate or college users behind shared NAT | Limits are keyed on session or account where possible, with IP limits set from observed NAT populations. |
Cloud provider WAF or a third-party WAAP like Cloudflare or Akamai?
If your applications sit on one cloud and your main problems are OWASP attacks, bots on login and sign-up, and DDoS, the native WAF is usually enough and far simpler to operate: AWS WAF with Bot Control and Fraud Control, Front Door Premium, or Cloud Armor with reCAPTCHA Enterprise. Choose a third-party WAAP when applications span several clouds and on-prem data centres and you want one policy, when you need advanced client-side script protection for PCI DSS payment pages, or when your traffic is large enough that bundled CDN pricing beats native egress. Avoid running both in series without clear ownership.
Key facts: Web Application Protection
Web Application Protection in Practice
2 Web Application Protection scenarios, from E-commerce marketplace (home furnishing and decor) and Government e-procurement technology vendor, plus related platform case studies.
Home-goods marketplace stops 91% of fake sign-ups farming referral coupons
E-tendering platform stays online on bid-closing days through a 40 Gbps flood
Health-tech SaaS moves patient data behind KMS and Identity Center ahead of DPDP
Real-estate developer handles 40x launch-day traffic on its booking portal
Web Application Protection: Frequently Asked Questions
What does web application protection cost to set up and run?
NTSPL's tuning engagement for two to five applications typically costs INR 6-12 lakh over six to seven weeks. Run costs vary: WAF and bot management are billed per rule and per million requests, often INR 30,000-2 lakh a month for Indian consumer apps, while DDoS response plans add a fixed annual or monthly fee.
Will a WAF stop credential stuffing?
A WAF alone with IP rate limits stops only crude attacks. Credential stuffing now uses residential proxies across thousands of IPs, so you need bot signals, client-side tokens and checks against known breached credentials, such as AWS WAF ATP or reCAPTCHA Enterprise signals, combined with MFA on the application.
Do government portals need anything specific?
Government websites and applications in India are generally expected to clear a security audit by a CERT-In-empanelled auditor before hosting. A tuned WAF does not replace that audit or code fixes, but it closes the OWASP findings auditors commonly retest while developers remediate, and provides logs for CERT-In incident reporting.
How do you avoid blocking genuine customers?
Every rule runs in count mode first through a peak day, and we measure matches against logged-in, paying sessions. Challenges replace blocks for uncertain traffic, synthetic checkout tests run continuously, and a false-positive report from customer support is reviewed within one business day.
Can the WAF protect mobile app APIs?
Yes. Mobile apps integrate the provider's SDK or reCAPTCHA mobile SDK to attach tokens to requests, which lets the WAF tell the genuine app from scripts calling the API directly. Schema validation at the API gateway then rejects malformed or undocumented calls.
Is this relevant to PCI DSS 4.0.1?
Yes. PCI DSS requirement 6.4.2 expects an automated technical solution that detects and prevents web attacks in front of public-facing web applications, and a tuned WAF in blocking mode meets that. Payment page script controls under 6.4.3 and 11.6.1 need separate client-side measures.