Indusface: Application Security, WAF and DDoS Protection Explained

Application security at the edge is a category that sounds like one product and is really four: a firewall that inspects requests, a scanner that finds weaknesses, mitigation that absorbs floods, and a delivery layer that makes the first three possible without adding latency. Vendors bundle them, which is sensible, and the bundling obscures what each part actually does — and therefore what it can and cannot protect you from.

This guide explains the mechanisms: how a web application firewall decides what to block, why false positives are the central operational challenge, how volumetric and application-layer floods differ, what bot management actually detects, and where this whole layer stops helping. Indusface is used as the reference point; the concepts apply to any comparable platform.

• What each component of an edge security platform does
• How a web application firewall inspects and decides, and its limits
• Managing false positives, which is where most deployments succeed or fail
• The difference between volumetric and application-layer denial of service
• Bot management, API protection and virtual patching
• Where edge security genuinely cannot help you

1. The four components
2. How a WAF works
3. Detection approaches
4. False positives and tuning
5. Deployment models
6. Denial of service: two different problems
7. Bot management
8. API protection
9. Vulnerability scanning
10. Virtual patching
11. TLS, certificates and privacy
12. Monitoring and incident response
13. What edge security cannot do
14. Choosing and evaluating
15. Twelve mistakes
16. A worked example: onboarding one application
17. Frequently asked questions

1. The four components

They sit together because they share a position — in front of your application, seeing every request — and because the signals overlap. A request pattern that looks like reconnaissance to the firewall looks like a bot to the bot classifier, and both benefit from knowing what the scanner found.

The delivery layer underneath matters too: since all traffic already passes through the platform's network, caching and content delivery come nearly free, which is why these products are usually sold together with performance benefits attached.

2. How a WAF works

A web application firewall terminates the connection, inspects the full request, decides, and forwards or blocks. Understanding what it inspects explains both its strengths and its blind spots.

It sees the method, path, query parameters, headers, cookies and body. It normalises them — decoding URL encoding, resolving character sets, unwrapping nested encodings — because attacks routinely hide behind layered encoding. It then evaluates rules against the normalised content and applies an action: allow, block, challenge, log, or rate limit.

Two properties follow directly. Normalisation is where much of the sophistication lives, because an attacker's job is to express the same payload in a form the inspector does not recognise but the application does. And the firewall does not know your application — it sees requests, not intent, which is why it can detect an injection pattern and cannot detect that a user accessed another customer's order by changing an identifier.

3. Detection approaches

Three approaches, used together in any serious product.

Signature matching compares requests against patterns of known attacks. Fast, precise for known techniques, and blind to novel ones. This is the foundation and it is not sufficient alone.

Behavioural and anomaly detection establishes what normal traffic looks like for your application — typical parameter lengths, expected value types, usual request rates — and flags deviation. This catches novel attacks and produces more false positives, because unusual is not the same as malicious.

Reputation and threat intelligence uses knowledge about the source: addresses known for attacks, networks associated with automated abuse, patterns observed across many customers. This is where a managed platform has a genuine advantage over a self-hosted firewall — it sees attacks against other customers before they reach you.

The layering matters because each covers the others' weaknesses. Signatures give precision, behaviour gives coverage, and reputation gives early warning.

4. False positives and tuning

This is where deployments succeed or fail, and it deserves more attention than the detection technology.

A firewall that blocks legitimate traffic is worse than no firewall, because it costs revenue and generates support load. The usual causes are a rich-text editor submitting content that resembles script injection, a search field containing characters that resemble query syntax, a file upload with unusual encoding, or an integration partner sending a payload shape nobody anticipated.

The process that works:

1. Start in monitoring mode. Log what would have been blocked, block nothing. Run for at least two weeks to cover a full business cycle including month-end and any batch integrations.
2. Review what would have been blocked. Separate genuine attacks from legitimate traffic. The legitimate ones tell you exactly which rules need exceptions.
3. Tune with narrow exceptions. Disable a specific rule for a specific path or parameter, never a whole rule category globally. Broad exceptions create holes that outlive the reason for them.
4. Enable blocking progressively, starting with high-confidence rules and expanding.
5. Review continuously. Application changes introduce new traffic patterns, and a rule that was fine last quarter may block a new feature.

The organisational point matters as much as the technical one: someone must own this. A firewall in blocking mode with nobody reviewing its decisions will eventually block something important during a busy period, and the response will be to disable it entirely.

5. Deployment models

The cloud proxy model dominates because it requires no infrastructure change and it is the only model that can absorb a large volumetric flood — you cannot filter a flood that has already saturated your own connection.

Its critical operational requirement is hiding the origin. If an attacker can determine your servers' real addresses, they bypass the protection entirely by connecting directly. That means restricting your origin firewall to accept traffic only from the provider's networks, and removing historical DNS records that reveal the real address. This step is skipped surprisingly often, and it invalidates the entire deployment.

6. Denial of service: two different problems

Volumetric and application-layer attacks require completely different defences, and conflating them leads to buying protection against one while being vulnerable to the other.

Volumetric attacks aim to saturate bandwidth with enormous traffic volumes, frequently amplified through misconfigured third-party services. The defence is capacity plus filtering upstream: the provider's network absorbs the flood and forwards only clean traffic. You cannot defend against this yourself, because by the time traffic reaches your connection the connection is already full.

Application-layer attacks send comparatively modest volumes of requests designed to be expensive — a search endpoint with a costly query, a login page that triggers a database lookup and a hash computation, a report generation endpoint. The traffic volume may be unremarkable while the server is overwhelmed. The defence is behavioural: rate limiting per source and per endpoint, challenges for suspicious clients, and caching so repeated requests never reach the application.

The second kind is more common against ordinary businesses, harder to detect, and frequently indistinguishable from a legitimate traffic spike at first glance. Rate limits calibrated per endpoint according to cost are the most effective single control, and they are configuration rather than a purchase.

7. Bot management

A substantial share of web traffic is automated, and much of it is neither malicious nor welcome. Bot management distinguishes categories and applies different treatment.

The classification signals: whether the client executes JavaScript and renders as a browser would, consistency between the declared client and its actual behaviour, network-level fingerprinting, behavioural patterns such as navigation speed and mouse movement, and reputation of the source.

The categories worth distinguishing:

• Good bots — search engine crawlers, monitoring, legitimate partner integrations. Allow, and verify their identity rather than trusting the declared client string, which is trivially forged.
• Grey bots — price scrapers, aggregators, research crawlers. A business decision rather than a security one: some are competitors, some drive traffic.
• Malicious bots — credential stuffing, card testing, inventory hoarding, vulnerability scanning. Block or challenge.

The most damaging category for many businesses is credential stuffing: automated login attempts using credentials leaked from elsewhere. It looks like ordinary login traffic distributed across many addresses, which is why volume-based rate limiting misses it, and why behavioural detection plus multi-factor authentication matters more than any firewall rule.

8. API protection

APIs now carry a large share of traffic and have different characteristics from browser traffic: no JavaScript execution, no user behaviour to observe, structured payloads, and machine clients that legitimately send high volumes.

The controls that apply specifically:

Schema validation against a specification, rejecting requests that do not conform before they reach your application. This is the most effective API control available and requires a maintained specification, which is a reason to keep one beyond documentation.

Per-consumer rate limiting rather than per-address, since a single partner may legitimately send far more than a browser and multiple partners may share an address.

Discovery of undocumented endpoints. Platforms observe traffic and identify endpoints not in your specification — old versions, debug routes, forgotten integrations. Shadow APIs are a common and genuinely dangerous exposure, because they are unmonitored by definition.

Sensitive data detection in responses, flagging endpoints returning personal or financial data so you can verify that authorisation is appropriate.

What the edge cannot do for APIs is authorisation. Whether this authenticated caller may access this particular record is a question only your application can answer, and it is the most common serious API vulnerability.

9. Vulnerability scanning

Scanning probes your running application the way an attacker would: crawling to discover pages and parameters, then submitting crafted inputs and interpreting the responses.

Its value is finding what you did not know about — a forgotten administrative interface, an unpatched component, a parameter that reflects input into the page. Its limits are equally clear: it cannot find authorisation flaws, business logic errors, or anything behind a workflow it cannot navigate.

Practical guidance: run authenticated scans as well as unauthenticated, because most of an application is behind a login and an unauthenticated scan sees almost nothing. Schedule regularly rather than annually, since applications change continuously. Feed results into your normal work tracking rather than a separate report. And treat manual penetration testing as complementary rather than replaceable — a scanner finds known patterns, a tester finds the logic flaw specific to your business.

10. Virtual patching

This is the capability that most justifies combining scanning with a firewall, and it is genuinely valuable.

When a vulnerability is found — by your scanner, by a researcher, or by a public disclosure affecting a component you use — fixing it properly requires a code change, testing and a release, which may take days or weeks. A virtual patch is a firewall rule that blocks the specific exploit pattern in the meantime.

The value is time. A serious vulnerability disclosed in a widely used component is exploited within hours of disclosure; a rule deployed in minutes closes that window while the real fix goes through your normal process.

Two disciplines keep it honest. Virtual patches are temporary, and each one needs a linked ticket for the real fix and a review date — otherwise they accumulate, nobody knows which are still needed, and the underlying vulnerabilities remain. And they are pattern-based, so a variant of the exploit may bypass them. Treat a virtual patch as a stopgap, never as a resolution.

11. TLS, certificates and privacy

A proxy-based platform terminates TLS, which means it decrypts your traffic. That is what makes inspection possible and it is also a consideration worth addressing explicitly rather than discovering later.

The questions to answer before onboarding: where is traffic decrypted geographically, what is logged and for how long, who at the provider can access it, is the connection to your origin re-encrypted, and what contractual commitments exist about data handling. For applications processing regulated data these are compliance questions with documented answers, not technicalities.

Operationally, most platforms manage certificates including automatic renewal, which removes a recurring source of outages — an expired certificate remains one of the most common self-inflicted incidents in web operations. Ensure the connection from the platform to your origin uses TLS as well; terminating at the edge and forwarding in plain text over the internet defeats a substantial part of the point.

12. Monitoring and incident response

The platform generates a great deal of data, and most of it is noise. The signals worth alerting on are few:

• A sharp rise in blocked requests, which indicates either an attack or a change in your application that broke a rule.
• A rise in legitimate traffic being blocked, which is the more expensive failure and is detectable as a drop in successful transactions alongside a rise in blocks.
• Traffic reaching the origin directly, which means the protection is being bypassed and the origin is exposed.
• Rate limit activation on business-critical endpoints, which may indicate abuse or may indicate a legitimate integration exceeding its allocation.
• New endpoints discovered that are not in your specification.

During an actual attack, the useful actions are narrower than people expect: raise rate limits' strictness on the targeted endpoints, enable challenges for suspicious clients, block obviously malicious sources, and — critically — verify that the origin is still not directly reachable. Attackers routinely probe for the real address during an attack precisely because the edge is doing its job.

13. What edge security cannot do

Being explicit about the boundary prevents the most dangerous outcome, which is assuming coverage you do not have.

• Authorisation flaws. A user changing an identifier to read another customer's data sends a perfectly well-formed request. Only your application knows it is wrong. This is the most prevalent serious web vulnerability and the edge cannot see it.
• Business logic abuse. Applying a discount code a thousand times, or exploiting a race condition in a booking flow, uses legitimate requests in an illegitimate sequence.
• Compromised credentials. An attacker with a valid session looks like a user.
• Vulnerable dependencies. A flaw in a library is in your code, not in your traffic. Dependency scanning is a separate control.
• Insider access and misconfiguration. A publicly readable storage bucket is not reached through your application.
• Anything not passing through it. Direct origin access, internal APIs, administrative interfaces on other hostnames.

The framing that helps: edge security is a control that buys time and removes noise. It stops opportunistic and automated attacks, which are the overwhelming majority by volume, and it gives you a place to respond quickly when something is disclosed. It does not replace secure development, dependency management, or authorisation done properly in code.

14. Choosing and evaluating

Feature matrices are a poor instrument, because every serious product claims every capability. These questions discriminate better:

For most organisations without a dedicated security team, the managed service aspect matters more than the detection technology. A well-tuned firewall with responsive support outperforms a technically superior product that nobody maintains.

15. Twelve mistakes

1. Enabling blocking immediately. Legitimate traffic blocked on day one, and the deployment loses credibility.
2. Not hiding the origin. The entire protection becomes bypassable.
3. Broad rule exceptions. A hole that outlives the reason for it.
4. Nobody owning the false positive queue. Something important gets blocked during a busy period.
5. Assuming coverage of authorisation flaws. The most prevalent serious vulnerability, invisible at the edge.
6. Unauthenticated scanning only. Almost the entire application unexamined.
7. Virtual patches with no expiry. Accumulating rules and unfixed vulnerabilities.
8. Plain-text between edge and origin. Defeats a substantial part of the point.
9. Volume-based rate limiting against credential stuffing. Distributed attacks stay under every threshold.
10. Trusting declared client identity for bots. Trivially forged; verify properly.
11. Alerting on everything. Noise trains everyone to ignore the console.
12. Treating it as the security programme. It is one layer, and the layers it does not cover are where serious breaches occur.

16. A worked example: onboarding one application

Consider putting an existing customer-facing web application behind a platform for the first time, with an integration partner that submits bulk data nightly and a rich-text editor in the administrative interface.

Week one is entirely monitoring. DNS is switched, traffic flows through the platform, and nothing is blocked. The value of this week is the list of what would have been blocked, which turns out to contain three categories: genuine automated attack traffic, roughly two hundred requests per day; the rich-text editor, whose HTML content triggers script-injection rules on every save; and the nightly partner integration, whose payload contains characters that resemble query syntax.

The origin is locked down before anything else. The origin firewall is restricted to accept connections only from the platform's networks, and historical DNS records pointing at the real address are removed. Without this step the remaining work would be decorative, and it is the step most commonly deferred.

Exceptions are written narrowly. The script-injection rules are disabled for the specific administrative path and the specific content parameter — not globally, and not for the whole rule category. The partner integration is handled by allowing its authenticated path with a distinct rate limit rather than by exempting its source address, which would have been simpler and would have created a hole usable by anyone who spoofed it.

Blocking is enabled progressively. High-confidence signature rules first, then behavioural rules a week later after another monitoring period, then rate limits calibrated per endpoint according to cost — the search and report endpoints get tighter limits than static pages, because they are the expensive ones an application-layer attack would target.

An authenticated scan runs against a staging copy. The unauthenticated scan found little, as expected. The authenticated scan finds an administrative interface reachable at a predictable path with no rate limiting on its login, and a report endpoint that reflects a parameter into the page. The first is fixed by restricting access; the second gets a virtual patch within the hour and a code fix within the week, with a ticket linking the two so the temporary rule is removed rather than forgotten.

Monitoring is narrowed to five alerts. A spike in blocks, a drop in successful transactions alongside a rise in blocks, any traffic reaching the origin directly, rate limiting on the checkout path, and any newly discovered endpoint. Everything else is available in the console and does not page anyone, because the alternative is an alert stream nobody reads.

Total elapsed time is about a month, most of it waiting deliberately in monitoring mode. The instinct to compress that into a day is what produces the deployments that get switched off in week three.

17. Frequently asked questions

Does a WAF make us secure?

It removes a large volume of opportunistic and automated attacks, and it buys time when a vulnerability is disclosed. It does not address authorisation flaws, business logic abuse, compromised credentials or vulnerable dependencies — which is where serious breaches typically originate. Treat it as one layer that handles the noisy majority, not as a substitute for secure development.

Will it slow our site down?

Inspection adds a small amount of latency, typically single-digit milliseconds. In practice most sites get faster, because the same platform provides content delivery and caching, and serving cached content from a nearby edge location more than offsets the inspection cost. Measure before and after rather than assuming in either direction.

How do we handle a false positive at three in the morning?

Decide the process before you need it: who has access to change rules, whether support can act on your behalf, and what the escalation path is. The practical mitigation is having a documented way to move a specific rule to monitoring mode quickly, which is far better than the alternative of disabling protection entirely under pressure — which is what happens when no process exists.

Is a cloud platform or an on-premises appliance better?

Cloud, for almost everyone. It is the only model that can absorb a volumetric flood, it requires no infrastructure, and the shared threat intelligence across many customers is a genuine advantage. On-premises makes sense when regulation prevents traffic leaving your control, or when the application is internal and never faces the internet.

How often should we scan?

Weekly or on every significant release, authenticated, against an environment that mirrors production. Annual scanning tells you about an application that no longer exists. Feed the findings into your ordinary work tracking so they compete for attention alongside everything else, rather than living in a security report nobody reads.

What about protecting internal applications?

The same controls apply, and the deployment differs — internal applications are frequently better served by a reverse proxy or by an identity-aware access layer that authenticates before traffic reaches the application at all. The assumption that internal means safe is wrong: a compromised workstation is inside your network, and internal applications are typically less hardened than public ones.

How do we protect against credential stuffing specifically?

Behavioural bot detection at the edge, plus multi-factor authentication in the application, plus monitoring for elevated failed-login rates across accounts rather than per account. Volume-based rate limiting alone fails, because a distributed attack stays below every per-source threshold while succeeding in aggregate. Checking submitted credentials against known breached password lists is also effective and inexpensive.

What should we do first?

Deploy in monitoring mode, lock down the origin so it accepts traffic only from the platform, and review a fortnight of would-have-blocked traffic before enabling anything. Those three steps account for most of the difference between a deployment that lasts and one that is disabled after its first false positive.

Glossary

Two entries decide whether a deployment survives. Origin exposure invalidates everything else — an attacker who finds the real address simply connects to it. And false positive handling determines whether the platform is still enabled in six months, because one blocked partner integration during a busy period, with no owner and no fast remediation path, results in the protection being switched off entirely.

Key takeaways

• Four components, one position. Firewall, DDoS mitigation, scanning and bot management share the edge and the signals.
• Monitor before blocking. Two weeks of would-have-blocked traffic is what makes tuning possible.
• Hide the origin, or nothing else matters. Restrict it to the platform's networks and remove old DNS records.
• Volumetric and application-layer floods need different defences. Capacity for one, behaviour and rate limits for the other.
• Virtual patches are temporary. Link each to a real fix with a review date.
• Authorisation flaws are invisible at the edge. The most prevalent serious vulnerability is your application's to solve.

Edge security is genuinely valuable and its value is specific: it removes the constant background noise of automated attacks, and it gives you a place to act within minutes when something is disclosed. Understanding precisely where that coverage ends is what stops it from becoming a reason to under-invest everywhere else.