Policy Insights
Administrators often need to evaluate the potential impact of App Security policies
before committing to enforcement. For example, when introducing new application
controls, an admin may want to verify that a newly crafted policy doesn't produce
unintended effects — such as blocking legitimate users or affecting unrelated
applications.
Setting a policy's status to Preview allows administrators to inspect the expected
outcome against live traffic without affecting it in any way. This same evaluation
capability applies to policies already in Enforced status, giving admins a way to
confirm that an active policy is producing the intended results.
Navigate to to view information about Recommended,
Previewed, or Enforced policies.
For each policy state, the page has three different tabs listing the
Recommended, Previewed, and
Enforced policies sorted by the number of hits within the
selected time interval. For instance, for the Enforced
policies, the selection is set on the top policy by number of hits and the admin can
observe:
- Creation Date—Time the policy was authored.
- Late update—Time the policy was last changed.
- Impacted users—Sources of policy hits in the selected time
interval.
- Impacted apps—Targeted apps for the policy hits in the selected time
interval.
- Map—Geographic distribution of the impacted users.
- Blocked requests—Represent the actual app requests
that were matched against this policy. The admin can click on the View
details of one of the requests and see all the critical request fields,
including IP, headers, and request methods.
- Affected Applications—Information about the
applications affected by the enforced policy.
Across all three tabs, administrators can take immediate action based on the data
presented:
- Fine-tune the policy—If the observed outcome is unexpected or incorrect, click
Edit to adjust the policy configuration.
- Promote or demote the policy—If the observed impact matches the intended
behavior, click Enforce or Preview
to update the policy's status accordingly.
In some cases, OWASP Top 10 protection rules may generate false positives depending
on the nature of the protected application. For example, an application that handles
developer code might include request payloads that legitimately contain code
snippets, which is content that could inadvertently trigger rules designed to detect
remote code execution or similar attacks.
To handle these situations efficiently, administrators can click on any individual
log entry to create an exception directly from that record. All relevant fields are
automatically populated, ensuring that future requests matching the same pattern no
longer generate alerts without requiring manual policy construction.
