NET / NET-06
Published application protection — WAF and API gateway
Add controls in front of exposed applications and APIs: request filtering, access restrictions and usage limits. This complements secure code without automatically fixing business-logic flaws.
WHEN IT HELPS
A focused response
to a defined need.
Exposed web application, customer-portal launch, partner-facing API or a need for interim controls before a vulnerability is fixed.
SCOPE & OUTCOMES
What the engagement covers.
Scope
- Endpoint mapping
- TLS termination
- WAF rules
- API authentication and quotas depending on architecture
- logging
- observation mode
- exceptions
- functional and security testing
Deliverables
- Publishing architecture
- protection policies
- certificate procedures
- documented rules
- test scenarios
- false-positive dashboard
- operations guide
Acceptance evidence
Business and partner workflows work; agreed test requests are blocked or flagged; exceptions are tracked; logs support event investigation.
DELIVERY
How the work is structured.
Approach
Map traffic; design and size; pilot; migrate gradually with rollback; test and document operations.
Prerequisites & responsibilities
Customer: networking, applications, carriers, change windows and business acceptance. Provider: design, migration and tests. Third-party access and TLS inspection require suitable approvals.
Scope factors
Sites, actual inspected throughput, traffic, rules, remote users, availability and integrations. Hardware, security subscriptions and recurring operations are separate.
Questions to clarify
Which applications are critical? Who owns the code and APIs? What legitimate traffic could an overly generic rule block?
IMPORTANT BOUNDARIES
A WAF replaces neither penetration testing nor code remediation. Volumetric DDoS protection is a separate scope to price with the relevant provider.
Changes preserve essential services and recovery paths. Sizing, licensing and acceptance tests reflect the features that will actually be enabled.
IN PRACTICE
Illustrative situations.
These examples describe possible engagements and target outcomes. They are not customer references or achieved results.
Scenario 01
An online retailer launches a new service. Project: deploy a WAF in observation mode, tune rules and enable protection. Target outcome: filtering compatible with orders and payments without claiming invulnerability.
Scenario 02
A partner API experiences excessive consumption. Project: per-client authentication, quotas and alerts. Target outcome: attributable and controlled usage; a data-authorisation flaw remains assigned to developers for correction.
Technology and reference context
Examples: cloud or application WAFs and API gateways; select according to protocols, hosting, data and logging capabilities.
The final technology set is agreed during scoping, based on interoperability, licensing, access rights and operating requirements.
CONNECTED SERVICES
Build the next step.
These services can complement the engagement. They are not automatically included.
START A CONVERSATION
Make the scope clear.
We will clarify the objective, dependencies and responsibilities of this service before proposing delivery.