Securing the SonicOS API: CORS and Bearer Token Session Check

CORS and Allow CORS Origins

Figure 2 — CORS is disabled by default. The Allow CORS Origins field defines the exceptions.

What the setting does

Enables or disables Cross-Origin Resource Sharing (CORS), which permits or blocks web pages from a different domain accessing this firewall’s resources.

When CORS is enabled, SonicOS requires an explicit allow list of permitted origins rather than allowing all origins. You enter these in the Allow CORS Origins field as IP addresses or domain names, including wildcard subdomain patterns. This gives you control over which external sites, if any, may make cross-origin API calls to the firewall.

In plain terms

Web browsers normally stop a page on one website from reading data from another website. That protection is what keeps a page you happen to open from quietly talking to your firewall.

• CORS disabled (default): the firewall does not grant any external website permission to read its API responses. This is the recommended setting.
• CORS enabled with specific origins listed: only the websites you name may make cross-origin API calls. Use this when you have a legitimate web application that needs to call the API from a browser.
• CORS enabled with no origins listed: not recommended. Enable CORS only together with a specific allow list.

When you need to enable it

Most customers do not. Leave CORS disabled unless you operate a browser-based application that calls the SonicOS API directly. Scripted and server-side integrations do not need CORS at all — see “Will this affect my API integrations?” below.

How to configure allowed origins

1. Navigate to Device | Settings | Administration | SonicOS API.
2. Set CORS to enabled.
3. In the Allow CORS Origins field, enter each permitted origin on its own line. You may use an IP address, a fully qualified domain name, or a wildcard subdomain pattern.
4. Click Accept.
5. Test your application. If it still cannot reach the API, confirm the origin you entered matches exactly what the browser sends, including the scheme and any port.

Keep the list as short as possible. Every entry is a website you are trusting to make authenticated calls to your firewall.

Non-GUI Management Login Bearer Token Session Check

Figure 3 — Non-GUI Management Login Bearer Token Session Check is enabled by default in SonicOS 7.3.4.

What the setting does

This option applies to non-GUI management login. The bearer token is checked for every API request call. The token is initially obtained from the /auth API response. The API client must include this bearer token in the HTTP header for all API requests after logging in. This setting is enabled by default in SonicOS 7.3.4.

In plain terms

With this setting enabled, every API request must carry its own proof that it belongs to a logged-in session. It is not enough for the request simply to come from the same computer that logged in earlier.

This matters because a web page open in a browser sends requests from the same computer as your management session. Requiring a token on each request means such a page cannot act on your session, because it has no way to obtain the token.

• SonicWall recommends leaving this setting enabled.
• If you disable it, API requests are associated with the session by source IP address alone, which is considerably weaker.

What your API client needs to do

1. Authenticate to the /auth endpoint as normal.
2. Read the bearer token from the /auth response.
3. Include that token in the HTTP header of every subsequent API request for the life of the session.
4. Obtain a fresh token when you re-authenticate.

Most SonicWall-supplied and third-party API clients already do this. If you maintain your own client and it does not yet send the token, update it before disabling the setting — do not disable the setting as a shortcut.

In earlier releases, an API session was associated with the source IP address of the administrator’s workstation, and API responses permitted cross-origin access without restriction. In combination, these two behaviors meant that a web page open in an administrator’s browser could issue API requests that the firewall accepted as part of the active management session.

The two settings described above close that gap. The bearer token check ensures each request proves it belongs to the session. Disabling CORS by default ensures the firewall does not grant external websites permission to read API responses.