Application security
Protect the applications and APIs you run, without handing traffic to someone else's network.
Nexus Shield inspects requests to your applications and APIs against policy your own team authors, blocks or flags what matches, and logs every decision inside your environment.
- WAF and API defenses
- Self-hostedWAF and API defenses
- policy, versioned and attributable
- Team-ownedpolicy, versioned and attributable
- every request decision
- Loggedevery request decision
- blocked events reach a review
- Workflow-linkedblocked events reach a review
The buyer problem
Application protection usually means routing traffic through a network you do not control.
A cloud-fronted WAF requires your application traffic to pass through a third party's infrastructure. For an application handling regulated data, or an API serving an internal system that must never leave the network boundary, that requirement rules the option out before evaluation even starts.
Meanwhile, rule changes go through a support ticket or vendor console, and decision logs live wherever the vendor decided to keep them, on the vendor's retention terms.
What changes
From a vendor-run gateway to team-owned protection.
- Where traffic goes
- Requests are inspected inside your own environment, in the same network boundary as the application, rather than routed through a third-party edge network.
- Who owns the policy
- Your application security team authors and versions the rule set and API policy directly, without going through a vendor support process.
- Where the evidence lives
- Request and decision logs are retained inside your environment on your own retention schedule.
- What happens after a block
- A blocked or flagged event can trigger a Nexus workflow for review, instead of sitting unseen in a separate log.
How it works mechanically
Register, author policy, monitor, enforce, iterate.
Register the application or API
The application or API endpoint is registered with Shield and placed in the request path Shield will inspect.
Author the initial policy
A starting rule set and, for APIs, a schema and rate policy are authored by your application security team.
Run in monitor mode
Shield inspects traffic and logs decisions without blocking, so the team can confirm the policy does not flag legitimate traffic.
Switch to enforce mode
Once the policy is tuned, Shield begins blocking requests that match the rule set, with every decision still logged.
Iterate the policy
New attack patterns or false positives are addressed by updating the rule set, with each change versioned and attributable.
Worked example
A new payments API goes live behind Shield.
Illustrative rollout
Representative output, not a live customer instance
- POST /api/payments/initiateMonitor mode, week 10 blocks, 3 flagged for review
- POST /api/payments/initiateSchema tightened after reviewPolicy updated
- POST /api/payments/initiateEnforce mode, week 22 malformed requests blocked
- GET /api/payments/statusNo policy matchAllowed
Monitor mode lets the team confirm policy accuracy before requests are actually blocked in production.
What you get
A protected application with the policy and evidence in your hands.
What the solution delivers
A running Shield deployment in front of the registered application or API, a versioned rule set and API policy owned by your team, a decision log covering every inspected request, and, where configured, a workflow that opens on a block or flag for human review.
Where it deploys
Alongside the application it protects.
Deployment topology
Shield deploys in the same environment as the application or API it protects, on-premises, in a private cloud, in a sovereign cloud, or air-gapped.
Identity and access
Policy authoring access follows your existing SSO, MFA and RBAC, so only authorised engineers can change a live rule set.
Architecture session
Put your next application or API behind protection you control.
We will scope a Shield deployment for a specific application or API and walk through policy authoring end to end.