Security rules

Security rules harden the Prisma Browser: they govern extensions, cookies, network APIs, certificate trust, key protection, session refresh, HTTPS enforcement, and dozens of other protections. A security rule carries a controls map, where each key is a named control and its value is that control's settings. See Policy overview for the concepts shared by all policy types.

note

The Policy APIs are in Beta and are enabled by request. Contact your account team to join the Beta program.

Base path: /seb-api/v1/policy/security.

Mandatory fields

Field	Required	Notes
`name`	Yes	1 to 300 characters
`mode`	Yes	`active` or `disabled`
`controls`	Yes	A map of control name to settings. Add at least one control to enforce policy.
`scope`	No (recommended)	Who the rule applies to. Omitting it applies the rule to everyone.
`description`	No	Up to 300 characters

How controls work

Each control is addressed by name and replaced as a whole. Most controls take a single action (typically allow/block or enable/disable); some carry richer settings (for example the extensions control has a mode and an extensions[] list).

{
  "name": "Browser hardening - all users",
  "mode": "active",
  "scope": { "users": { "isAny": true } },
  "controls": {
    "developerToolsForExtensions": { "action": "block" },
    "allowedOrBlockedExtensions": {
      "mode": "blockByListOrRisk",
      "riskLevel": "high"
    }
  }
}

developerToolsForExtensions allows or blocks extensions that users load by drag and drop or in developer mode. It does not control DevTools on web pages: that is the developerToolsOnWebPages data control on access and data rules.

Create a security rule

POST /seb-api/v1/policy/security/rules

Show request and response

curl -sS -X POST "$PB_API_BASE/policy/security/rules" \
  -H "Authorization: Bearer $PB_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
        "name": "Block sideloaded extensions",
        "mode": "active",
        "scope": { "users": { "isAny": true } },
        "controls": { "developerToolsForExtensions": { "action": "block" } }
      }'

Response:

The resolved rule: the fields you sent, every server-side default filled in, and the new id.

Delete a security rule

curl -sS -X DELETE "$PB_API_BASE/policy/security/rules/$RULE_ID" \
  -H "Authorization: Bearer $PB_TOKEN"

Returns 204 with an empty body.

Sections

Security sections are created with POST /seb-api/v1/policy/security/sections (only name is required) and ordered with the positions endpoints.

note

Every write edits the draft. Publish to make it live (see Draft and publish).

Examples

Expand an example to see the request, response, and notes.

Baseline browser hardening for everyone

A single rule that turns on a handful of common protections. Omitting scope (or using isAny) applies it to all users. Each control is a spec-defined key: developerToolsForExtensions (extensions loaded by drag and drop or developer mode) and basicAuthenticationOverHttp take allow/block; cookiesProtection takes enable/disable.

curl -sS -X POST "$PB_API_BASE/policy/security/rules" \
  -H "Authorization: Bearer $PB_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
        "name": "Browser hardening - all users",
        "mode": "active",
        "scope": { "users": { "isAny": true } },
        "controls": {
          "developerToolsForExtensions": { "action": "block" },
          "cookiesProtection": { "action": "enable" },
          "pagesWithSslErrors": { "action": "block" },
          "basicAuthenticationOverHttp": { "action": "block" }
        }
      }'

Response (201):

The resolved rule: the fields you sent, every server-side default filled in, and the new id.

Protect keys, time out idle sessions, and enforce HTTPS

Three controls for endpoint and session hardening:

hardwareBackedKeysProtection (enable/disable): the Prisma Browser protects its cryptographic keys with hardware and OS-level mechanisms, such as the TPM and platform key stores, using the strongest protection available on the endpoint.
sessionRefresh: requires the user to re-authenticate. Besides maxSessionDuration and onBrowserClosed, it accepts inactivityTimeout, the idle time before re-authentication: 1min, 2min, 5min, 15min, 30min, 45min, or 1hour.
forceHttps: forces HTTPS instead of HTTP. Set blockBypass: true to remove the option to proceed past the HTTPS warning page.

curl -sS -X POST "$PB_API_BASE/policy/security/rules" \
  -H "Authorization: Bearer $PB_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
        "name": "Endpoint and session hardening",
        "mode": "active",
        "scope": { "users": { "isAny": true } },
        "controls": {
          "hardwareBackedKeysProtection": { "action": "enable" },
          "sessionRefresh": { "action": "enable", "maxSessionDuration": "12hours", "inactivityTimeout": "30min" },
          "forceHttps": { "action": "enable", "blockBypass": true }
        }
      }'

Response (201):

The resolved rule: the fields you sent, every server-side default filled in, and the new id.

Allow only specific extensions (allow-list)

Use the allowedOrBlockedExtensions control with mode: "allowByList" and one entry per Chrome extension ID. Each ID is 32 lowercase letters a through p.

curl -sS -X POST "$PB_API_BASE/policy/security/rules" \
  -H "Authorization: Bearer $PB_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
        "name": "Approved extensions only",
        "mode": "active",
        "scope": { "users": { "isAny": true } },
        "controls": {
          "allowedOrBlockedExtensions": {
            "mode": "allowByList",
            "extensions": [
              { "id": "cjpalhdlnbpafiamejdnhcphjbkeiagm" }
            ]
          }
        }
      }'

Response (201):

The resolved rule: the fields you sent, every server-side default filled in, and the new id.

Note: to add or remove one extension later, GET the rule, edit the extensions array, and PATCH the whole allowedOrBlockedExtensions control back (controls have no per-item delta). See Manage allowed browser extensions.

Block risky extensions by risk score

Block extensions at or above a risk threshold with mode: "blockByListOrRisk" and a riskLevel of malicious, medium, or high. The other valid modes are allowAll and blockAll.

curl -sS -X POST "$PB_API_BASE/policy/security/rules" \
  -H "Authorization: Bearer $PB_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
        "name": "Block high-risk extensions",
        "mode": "active",
        "controls": {
          "allowedOrBlockedExtensions": {
            "mode": "blockByListOrRisk",
            "riskLevel": "high"
          }
        }
      }'

Response (201):

The resolved rule: the fields you sent, every server-side default filled in, and the new id.

Switch a control on an existing rule (PATCH replaces the whole control)

PATCH replaces the named control whole. Here the extensions control is switched to an allow-list; controls you do not mention are left untouched. Because there is no per-item delta, send the complete extensions array you want.

curl -sS -X PATCH "$PB_API_BASE/policy/security/rules/$RULE_ID" \
  -H "Authorization: Bearer $PB_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
        "controls": {
          "allowedOrBlockedExtensions": {
            "mode": "allowByList",
            "extensions": [
              { "id": "hdokiejnpimakedhajhdlcegeplioahd" },
              { "id": "cjpalhdlnbpafiamejdnhcphjbkeiagm" }
            ]
          }
        }
      }'

Response (200):

{ "id": "0RLEXAMPLESECURITYRULEXXXXX" }

Security rules

Mandatory fields​

How controls work​

Create a security rule​

Delete a security rule​

Sections​

Examples​

Related​

Mandatory fields

How controls work

Create a security rule

Delete a security rule

Sections

Examples

Related