- Define browser-side rules where you already define everything else
- Control what scripts can access
- Investigate violations where you already investigate threats
- Client-side script visibility and modern AI applications
- One policy model for the entire application attack surface
Key takeaways
Third-party JavaScript executes outside server-side WAF controls, exposing applications to client-side data harvesting and script injection.
Akamai Application Protection Platform now unifies browser-side rules and server-side web application and API protection (WAAP) policies in a single management console.
Client-side threat telemetry lands directly in Web Security Analytics (WSA) for streamlined cross-layer incident investigation.
JavaScript runs inside nearly every modern web application. It powers integrations, dynamic content, payment flows, and user experience features. It also runs in the browser — outside the server-side controls that application security teams have traditionally managed.
That creates a gap that attackers know how to exploit. Script injection, form data exfiltration, and credential harvesting operate on the client side, in a space that standard WAF and API protection controls don't reach. Protecting against this has historically meant a separate security product, separate configuration, and a separate investigation workflow.
We've changed that.
Define browser-side rules where you already define everything else
Akamai Application Protection Platform now includes native client-side protection. Security teams can create client-side rules directly inside application protection security policies: the same place that they configure WAF rules, bot defenses, and API protections.
This isn't a separate console or a bolt-on; it's a dedicated section within the existing policy experience, built to work the same way.
Rules can target specific pages, first-party scripts, third-party scripts, or individual scripts by URL. You can apply a rule broadly across all pages, or focus it on a specific page and hostname combination — which matters when the protection level for a payment checkout or login form needs to be different from the rest of the application.
Control what scripts can access
The browser gives JavaScript access to things that matter: sensitive form fields, network destinations, cookies, local and session storage. A misconfigured or compromised script can reach any of them.
Client-side protection rules let you define which scripts are allowed to do what. Rules can restrict access to sensitive data inputs, network connections, cookies, and browser storage with three available enforcement modes: Monitor activity, generate a violation, or actively deny it.
Teams can start by monitoring to understand what's running on their pages and what it's doing, then move to enforcement as confidence in the policy grows. That progression is built into the experience.
Investigate violations where you already investigate threats
When a client-side rule fires, the violation lands in Web Security Analytics (WSA). In addition to the server-side data already in WSA, you see:
- The triggered rule
The triggered rule
- The script involved
The script involved
- The activity type
The activity type
- The JavaScript method
The JavaScript method
- The matching selector
The matching selector
- Relevant contextual detail
Relevant contextual detail
A purpose-built client-side view surfaces this activity across rules, scripts, hostnames, paths, browser types, and geographies. There's no new investigation tool to learn. The data lives in WSA, where the rest of your application threat investigation already happens.
Client-side script visibility and modern AI applications
As enterprises embed client-side AI assistants, third-party LLM chat widgets, and browser-native inference scripts into their web apps, client-side exposure expands dramatically. Malicious scripts can hijack local prompt inputs or intercept AI response payloads right in the browser. By extending Akamai Application Protection Platform to the client side, AppSec teams gain unified visibility across both traditional JavaScript dependencies and emerging client-side AI data paths.
One policy model for the entire application attack surface
Browser-side threats and server-side threats affect the same application. Investigating them in the same place, under the same policy model, changes how security teams can operate.
Security architects can include client-side controls in the same policy that they use for the rest of their application protection posture. Application security engineers can investigate client-side violations without switching to a separate product. SOC analysts responding to an incident can see client-side behavior in the same view that they're already using.
The practical value of platform coverage is not that any individual capability is new, but that it's no longer fragmented.
