Securing Sophos Firewall XML API Access

The XML API of the Sophos Firewall is useful for automation, monitoring, backups, evaluations, and integrations. For this reason, it is also part of the management attack surface. Allowing API access gives a system the ability to read configuration data or make changes depending on permissions.

API access should therefore not be broadly allowed from internal networks or arbitrary sources. It is better to have a small, documented set of management networks, automation hosts, or fixed partner accesses.

Since SFOS 22, Sophos has expanded API access control. The API access settings are located under Administration > API access, and allowed sources can be defined as IP hosts. This allows not only individual IP addresses but also IP ranges and networks to be cleanly modeled.

When XML API Access is Useful

The XML API is not a standard access for normal admin work. Its use is sensible when there is a specific technical process behind it.

Typical use cases:

• Monitoring or inventory.
• Automated configuration checks.
• Backup or documentation processes.
• MSP or integration platforms.
• Scripts for recurring administrative tasks.
• Prepared changes from tools like Sophos Firewall Config Studio.

If a process can manage without the API, API access should not remain enabled as a precaution. Every additional interface needs an owner, a source, an access concept, and control.

What Changed with SFOS 22

With SFOS 22, XML API access control has become significantly more manageable for operations:

• The API access settings have been moved to the Administration > API access menu.
• API access is disabled by default and must be enabled deliberately.
• API access can be restricted to IP hosts.
• As sources, IP addresses, IP ranges, and networks are possible.
• Up to 64 IP hosts can be allowed.
• During the upgrade, previously allowed IP addresses are automatically converted into IP host objects.
• Migrated objects receive the prefix apiconfig.

This is helpful for operations because API sources no longer need to be maintained as loose individual addresses. A management network, an automation host, or a dedicated host group can be cleanly named and later recognized in reviews.

Basic rule: allow API only from defined sources

API access should be treated like WebAdmin or SSH: as narrow as possible, as broad as necessary.

Useful sources include:

• a dedicated automation server,
• a monitoring system,
• a configuration management host,
• an internal management network,
• a VPN or admin network,
• a clearly defined partner or MSP source address.

Not useful are:

• entire client networks,
• guest or IoT networks,
• Any,
• vague “whole server network” exceptions,
• temporary test IP addresses that are later forgotten.

If external service providers need API access, the source should be defined as specifically as possible. It should also be documented what the access is used for and when it will be removed.

Recommended procedure

The exact UI path can vary slightly depending on the SFOS version. In SFOS 22, the API configuration is under Administration > API access.

Practical procedure:

1. Check which system needs API access.
2. Under Hosts and services > IP host, create a clear IP Host object for this system.
3. If several sources are required, name IP Hosts, IP ranges or networks cleanly.
4. Under Administration > API access, enable API access.
5. Under Allowed IP hosts, allow only these objects.
6. Click Apply.
7. Do not add broad client or server networks.
8. Test access from the real automation or monitoring host, not from the admin notebook.
9. Remove sources that are no longer required.
10. Document the change in the change process.

For existing installations after an upgrade to SFOS 22, also search for objects with the apiconfig prefix. These objects were created from older API allow entries and should be checked, renamed or cleaned up.

Test access deliberately

The API endpoint is typically:

https://<Firewall-IP-or-hostname>:<Port>/webconsole/APIController

The port is the HTTPS port of the WebAdmin Console. If the admin port was changed under Administration > Admin settings, the API tool must use the same port. The API works with XML payloads over HTTP POST, not like a classic REST API with separate GET, POST, PUT and DELETE endpoints.

A useful test does not only answer whether login is possible at all. It should show whether the correct source is allowed, whether the account may perform the required operation and whether the result remains traceable in the audit or change process.

For acceptance, check these points separately:

• Source: The test runs from the real automation, monitoring or integration host, not from the admin notebook.
• Access: The firewall accepts the source IP only when the matching IP Host object is allowed in API access.
• Account: The API or service account used has only the required rights.
• Secret: Usernames, passwords or tokens do not end up in shell history, tickets, chat logs or screenshots.
• Audit: The access or change is traceable in the audit or change process.
• Rollback: Before write operations, a backup, rollback point and harmless read test exist.

curl examples with username and password in the URL are quickly copied and later hard to remove from logs. A short test with a dedicated service account, temporary test secret, secure storage and later rotation is safer if a secret was used in an unsafe context.

For structured tests, a Postman collection is often cleaner than a quickly copied shell command. Firewall address, port, username, password and object values should also be maintained as variables or secrets there, not hardcoded in requests, screenshots or tickets. The collection is not a security concept, but it helps test read and write operations more reproducibly.

An API that is reachable is not proof that the planned change is technically safe. Before productive write operations, a harmless read query should work first, followed by a small, controlled change.

API Access and User Rights

A source IP alone is not a complete security concept. The restriction only limits from where the API is reachable. Additionally, it must be clear which account is used for API access and what rights this account has.

For productive environments, you should check:

• Is a separate API or service account used?
• Does the account have only the necessary permissions?
• Is it clearly documented which person or team is responsible for the account?
• Is the password or secret stored securely?
• Is access removed when the integration is no longer used?
• Are changes traceable through audit logs?

Shared admin accounts are problematic for API processes. If multiple systems or people use the same account, traceability is weaker. For change analyses, checking Sophos Firewall Audit Trail Logs is relevant.

For a dedicated API account, a narrow process is better than a quickly copied full admin. Sophos documentation refers to this concept as Allow API access to administrators: it is not only the source that is allowed, the administrator or profile must also have the appropriate access.

1. Create an administrator profile with the required rights under Profiles > Device access.
2. Create an administrator user for the API process under Authentication > Users.
3. Assign the appropriate administrator profile.
4. If the access is only needed temporarily, limit Access time.
5. If possible, restrict Login restriction for device access to the intended sources.
6. Then allow API access and Device Access for the appropriate source.

Sophos supports the official APIs and unchanged sample scripts. Custom integrations, wrappers and automations still need an internal owner, tests and a rollback concept. “Works in the lab” is not enough for production write operations.

MFA and API users after SFOS 22

MFA is important for interactive administrator access. For API and automation processes, however, authentication must be planned deliberately. A script, monitoring tool or integration system cannot simply enter an OTP code if the user account enforces MFA.

The Known Issues list documents a special SFOS 22 case: after an upgrade, API-based configuration changes can fail for migrated users when MFA is active and no one-time token is supplied. Non-migrated users may behave differently in some cases. For operations, the important point is not to disable MFA everywhere, but to separate API accounts cleanly.

Recommended approach:

1. Use a dedicated service account for API processes.
2. Give the account only the required rights.
3. Additionally restrict API access to fixed IP Hosts or management networks.
4. Check whether MFA is technically and operationally sensible for this account.
5. If MFA is not practical for the API account, control the account especially tightly through source, permissions, secret storage and audit trail.
6. After an SFOS 22 upgrade, test all API processes with read and write operations.

⚠️ API users without MFA are not a free pass for broad rights. If an API account must run without MFA for technical reasons, source IP, rights, password storage, ownership and auditability must be controlled more tightly.

This point is particularly important for automations that do not only read but also change configuration.

Before productive API changes, check at least three things:

• A current Sophos Firewall backup exists.
• The planned API account can successfully perform a harmless read query.
• For prepared bulk changes from Sophos Firewall Config Studio, the generated API or curl calls work with the planned account.

Distinction from Device Access

API access control is not the same as Device Access, but both controls interact. Device Access controls local firewall services such as WebAdmin, SSH, User Portal, VPN Portal, DNS, or Ping. The API access settings additionally control which IP hosts may use the XML API. Important: the Device Access permissions for the WebAdmin Console also apply to API access.

In practice, this means that API access must be enabled, the source must be allowed in the API access settings, and local management access to the firewall must not be blocked by Device Access. Each layer limits a different part of the attack surface:

• Properly configure Device Access: local firewall services like WebAdmin, SSH, User Portal, VPN Portal, DNS, or Ping
• API access control: IP hosts that may additionally use the XML API
• Enable MFA for Sophos Firewall WebAdmin, VPN Portal, and Remote Access: interactive logins for WebAdmin, VPN Portal, and Remote Access
• Named Admins and clear roles: traceability and damage radius of admin and service accounts

If an admin network is allowed to use WebAdmin, SSH, and API, this network should be particularly well protected. A compromised client in the management network is otherwise a direct entry into firewall management.

Operation and Review

API access should be regularly reviewed. Especially after migrations, service provider changes, automation projects, or firewall upgrades, old sources often remain.

Sensible review questions:

• Which IP hosts are currently allowed API access?
• Are there objects with the prefix apiconfig?
• Are these objects still necessary?
• Do names and descriptions match the actual purpose?
• Are there documented responsible parties?
• Are API accesses considered in a change or audit process?
• Is there a current backup before major API-based changes?

Before API-based changes, a backup should always be available. The article Create or restore a Sophos Firewall backup describes what to consider for backup, restore, and compatibility.

Typical errors

• API access allowed for a whole client network: Every compromised client in that network can reach the API.
• Old apiconfig objects not checked: Migrated legacy exceptions remain active unnoticed.
• Service account uses full admin rights: A compromised secret has an unnecessarily large blast radius.
• API automation uses an MFA-required admin: Script or tool can fail on write operations after an SFOS upgrade.
• Wrong port in the tool: The admin HTTPS port was changed, but the tool still uses the old port.
• REST logic expected: The tool sends REST methods instead of an XML payload over HTTP POST to APIController.
• Temporary provider IP remains active: External access remains possible longer than planned.
• No documentation of the purpose: Later admins do not know whether an exception is still required.
• API changes without backup: Faulty automation is harder to roll back.

Troubleshooting

If a tool does not reach the XML API, you should check systematically:

1. Does the source IP match from the firewall’s perspective?
2. Is the source allowed as an IP host, IP range, or network?
3. Was an apiconfig object created after an upgrade but not properly adjusted?
4. Does Device Access allow local WebAdmin/API access from this zone?
5. Does the tool use the correct firewall address and the correct admin HTTPS port?
6. Do username, password, or secret match?
7. Does the account have the necessary rights?
8. Does the account enforce MFA although the tool cannot provide a one-time token?
9. Are there routing, NAT, or proxy effects between the tool and the firewall?
10. Was access intentionally removed by a hardening measure?
11. Was the test performed from the correct source system or only from the admin client?

If an API change has unexpected effects, first secure the last backup and then check the audit trail, Config Studio comparison, and affected firewall objects. For live traffic problems, Log Viewer and Packet Capture are more helpful than the API itself.

Checklist

Before activation:

• Document the purpose of API access.
• Clearly determine the source system.
• Create an IP host object with a descriptive name.
• Check service account and permissions.
• Deliberately set the MFA behavior of the API account.
• Establish a backup and rollback process.
• Define a test method without secret leakage.

During operation:

• Allow API access only for defined sources.
• Do not allow broad client, guest, or IoT networks.
• Check apiconfig objects after upgrades.
• Control service provider accesses temporally and technically.
• Store secrets securely and renew them when personnel or tools change.
• Rotate secrets if they ended up in shell history, tickets, or unsafe storage.
• Specifically test API read and write operations after SFOS upgrades.

During review:

• Regularly check allowed API sources.
• Remove IP hosts that are no longer needed.
• Match changes with audit trail and change tickets.
• Test automation processes after firmware updates.

FAQ