Security FAQ

Security FAQ

Answers to the questions security teams usually ask when approving Magic Toolbox for use. Everything here is based on how the app is built today; if something changes in a future release, this page will be updated.

Contents

• Does the app use TLS, and which version?
• How is data encrypted at rest?
• Where is the data stored?
• Are any cloud services involved that store data?
• What level of access does the app need?
• Can the app change or delete data in Jamf Pro?
• What happens to the data once a task is finished?
• Are API tokens destroyed after use?
• What does debug mode change?
• What else should a security team know?
• Recommended controls

---

Does the app use TLS, and which version?

Yes, as long as the server address uses https://. All connections use Apple's standard networking stack (URLSession).

App Transport Security (ATS) is relaxed. The app sets NSAllowsArbitraryLoads, so ATS doesn't block plain HTTP or enforce its usual TLS rules. In practice:

• HTTPS is the default, not a rule. If you enter a server name without https://, the app adds it. If you type http:// yourself, the app uses plain HTTP, and your credentials and token are sent unencrypted.
• A warning appears when you type an http:// address in a tool's credentials form. There's no warning when you add an http:// address under Saved Servers, or when a tool uses that saved server.
• Compare always switches its comparison traffic to HTTPS. Its first sign-in and permission check still use the address as you typed it.
• The app doesn't set a minimum TLS version. ATS would normally require TLS 1.2 or later; with this setting, that floor doesn't apply. The version used is whatever macOS and the server agree on: TLS 1.3 where the server supports it.
• Certificates are still validated against the macOS system trust store. There's no code that overrides certificate checks, and no certificate pinning. A certificate your Mac doesn't trust stops the connection.
• The licence server address is built into the app and always uses HTTPS.

How is data encrypted at rest?

What	How it's protected
Jamf credentials: username/password or API client ID/secret	Saved only if you tick Save credentials to Keychain in a tool (off by default), add a server under Saved Servers, or pick a saved server in a tool (the app then keeps a copy for that tool). Stored in the macOS Keychain as after first unlock, this device only: encrypted, readable once the Mac has been unlocked after starting up, and never synced to iCloud or other devices.
Compare credentials	Separate Keychain items, saved only if you tick Save to Keychain (off by default). Stored as when unlocked, this device only: unreadable while the Mac is locked, and never synced.
Licence key and licence token	macOS Keychain, after first unlock, this device only.
Wipe backups, HTML reports, exported profiles and downloaded files	Written as normal files and not encrypted by the app. They rely on FileVault full-disk encryption.
Data pulled from Jamf Pro	Held in memory while the tool is using it.

Where is the data stored?

Only on the Mac running the app.

• Files you export go wherever you choose in a save or folder dialog.
• App preferences, inside the app's sandbox container, hold:
  • Saved Server names, URLs, usernames and client IDs (no secrets)
  • the trial start date and licence check times
  • reviewed Profile Conflicts
  • the organisation name and logo for reports
  • which tools have debug logging on
  • a bookmark to your home folder, if you grant access in Login Item Profiles
• Login Item Profiles rule sets: profiles.json in the app's Application Support folder, inside its sandbox container.
• Icons working folder: icons downloaded during a scan go to a temporary folder in the app's container (MagicToolbox-Icons-<id>). Scan Again deletes it. Abort doesn't.
• Debug log: memory only. See What does debug mode change?

Are any cloud services involved that store data?

No Jamf Pro data is sent to, or stored by, MDM Magic or any third-party cloud.

The app does make a few outbound connections besides your Jamf Pro servers:

Licence check

• Contacts a licence server hosted on Cloudflare Workers: magictoolboxlicenses.dan-df5.workers.dev.
• Sends the licence key and the Mac's hardware serial number, used to tie the licence to one Mac. If the serial number can't be read, the app sends a random ID it generates once and keeps in its preferences.
• The server stores the serial number and the activation date against the licence key. Deactivating clears both. It returns a signed licence token valid for 25 hours.
• It's contacted when you activate or deactivate, and at app launch when a licence is saved and its token has less than 12 hours left. The free trial doesn't contact it.
• If the server can't be reached, the app keeps working until the token expires, then for a further 72 hours. After that, the licence key and token are deleted from the Mac.
• The server code doesn't log licence keys or serial numbers. It logs error messages only. Cloudflare's own request logging and retention aren't set in the app or the server code, so they aren't covered here.

Downloads from links Jamf Pro provides

• Downloader: for packages, Jamf Pro returns a pre-signed download link from Jamf Cloud Distribution Service. The app downloads the package from that link, without a Jamf token. If that fails with a network error, it downloads through the Jamf Pro API instead.
• Icons and Clone: download icon images from the links in Jamf Pro. Some of these requests carry a Jamf token. See Are API tokens destroyed after use?

Nothing else. There are no update checks and no analytics. Links in the About and Licence windows open in your browser only when you click them.

What level of access does the app need?

It depends on the tool. Some tools only read. Others create, update or delete objects in Jamf Pro: see Can the app change or delete data in Jamf Pro?

Tool	Access to Jamf Pro
Compare, Profile Conflicts, Smart Group Audit, Downloader	Read only
Icons	Read. Icon upload access, plus Update Policies, only if you upload an icon or attach one to a policy
Unused	Read. Delete only if you delete items from the results
Clone	Read on the source. Create and Update on each destination
Restore	Create for every object type in the backup
Wipe	Read and Delete
PPPC Analyser, System Extensions, Web Content Filter, Notifications, Login Item Profiles	None for analysis. Read, Create and Update macOS Configuration Profiles when you click Upload
Inspector	None

The full list of privileges per tool is in Jamf API Permissions. An API client with a dedicated API role per job is recommended over username/password.

Permission check

• At sign-in, most tools read the account's own privileges and show which are Allowed or Denied. That needs Read API Integrations and Read API Roles (API client) or Read Accounts (username/password). Compare tests access with read requests instead.
• The check only reads. It never sends a test write or delete.
• It's a warning, not a block: you can click Proceed Anyway →. Profile uploads are the exception: they stop if Create macOS Configuration Profiles is missing.

On the Mac

• Runs as a standard user; no admin rights needed.
• Built with the App Sandbox and Hardened Runtime.
• Entitlements: outgoing network connections only (no incoming), read/write access to files and folders you pick, read/write access to the Downloads folder, and access to its own Keychain items.
• Runs one external program: /usr/bin/codesign, in Login Item Profiles, to read the Team ID of items it finds. Nothing else is launched.
• Packages and apps are read inside the app. Package scripts are analysed as text and never run.
• No access to the camera, microphone, location, contacts, calendars, USB or Bluetooth.

Can the app change or delete data in Jamf Pro?

Yes, in the tools below, and only when you start the action.

Tool	What it changes	Safeguards
Wipe	Permanently deletes every object you select, including PreStage enrolments, API roles and API clients. It can also delete related items that block a deletion, if you tick them.	Saves a full backup first unless you tick Skip backup. DELETE EVERYTHING SELECTED stays disabled until you tick "I understand this will permanently delete the selected objects". The categories "No category assigned" and "Unknown" are never deleted. Abort Wipe asks for confirmation.
Unused	Permanently deletes the packages, scripts, macOS configuration profiles, disabled policies or smart computer groups you select.	A confirmation prompt. No backup is made.
Clone	Creates objects on each destination. If an object with the same name already exists there, it's overwritten. It also creates missing categories, scripts and extension attributes, and uploads Self Service icons. Scope is removed unless you choose to clone it.	A review screen and a permission check for each destination. There's no separate confirmation prompt before it starts.
Restore	Creates objects from a Wipe backup, including API roles and API clients if the backup has them. Objects that already exist with the same name are duplicated.	You must tick "I understand — proceed with restore".
Profile builders	Creates an unsigned, computer-level macOS configuration profile. If a profile with the same name exists, its payload is replaced. The app sends no scope, category or site.	Only runs when you click Upload. Stops if the Create privilege is missing.
Icons	Uploads icons. Attach to a Policy… reads the whole policy, changes its Self Service icon and writes the whole policy back.	Only runs when you ask it to.

Restore trusts the backup file. It sends each object to the API endpoint recorded in the file, and doesn't check the file for tampering. Only restore backups you created and have kept secure.

What happens to the data once a task is finished?

With debug logging off (the default):

• API responses are held in memory while the results are on screen, and are gone when the app quits. None are written to disk unless you export them.
• Two things are written without an export: the Icons working folder and the Login Item Profiles rule sets. See Where is the data stored?
• Files you save stay until someone deletes them. Wipe backups hold the full configuration of every object of the supported types, including script contents and profile payloads. It doesn't include your Jamf credentials. If those objects contain secrets, so does the backup. Handle all exports under your organisation's data-handling policy.

Are API tokens destroyed after use?

Jamf Pro: only in Compare.

• Compare invalidates its tokens when you disconnect, start a new comparison or abort a scan. It calls invalidate-token for username/password sign-ins and oauth/revoke for API clients.
• Compare doesn't invalidate the token from its first sign-in and permission check, or tokens still open when you quit the app.
• Every other tool doesn't invalidate its tokens. They stay valid on the Jamf Pro server until they expire on Jamf Pro's schedule. Most tools sign in again for each step, so one session can leave several unexpired tokens.
• When a token expires during a task, the app signs in again for a new one.
• Tokens are held in memory only. They're never written to disk or to the debug log.

Tokens sent to other hosts. Two features download images with the Jamf token attached, from whatever link Jamf Pro returns:

• Clone: each policy's Self Service icon, using the source server's token.
• Icons: Self Service branding and Enrollment Customization images.

If those links point to a host other than your Jamf Pro server, that host receives a valid token. Other image and package downloads don't send a token.

Licence token: a signed token, valid for 25 hours, stored in the Keychain. It's deleted when you deactivate or when the licence server rejects it.

Client secrets and passwords are never logged. If they weren't saved to the Keychain, they're gone when the app quits.

What does debug mode change?

There's one debug option, set per tool and off by default:

Option	Where	What it writes
Debug logging	Preferences › Debug Logging	Messages to the in-app log viewer. Held in memory only and cleared when the app quits. Nothing is written to disk.

The log records server host names, object names and IDs, profile identifiers and error text returned by Jamf Pro. It never records credentials or tokens.

What else should a security team know?

• Local-only processing. There is no vendor backend holding Jamf data.
• No telemetry. No analytics, crash reporting or third-party code: the app uses only Apple's frameworks. It doesn't include an Apple privacy manifest.
• Self-contained reports. Exported HTML reports don't load any external scripts, fonts or images. Your report logo is embedded in the file.
• Plain HTTP is possible. See Does the app use TLS, and which version?
• Web Content Filter passwords. A server Password is shown as plain text in the form, and saved as plain text in the .mobileconfig and in the profile uploaded to Jamf Pro.
• Licence tied to hardware. The licence server holds the Mac's serial number for as long as the licence is active on it.

Recommended controls

• Use https:// addresses only. On self-hosted Jamf Pro, turn off plain HTTP and TLS versions below 1.2 on the server.
• Use a dedicated, least-privilege API client for each job. See Suggested roles.
• Never give Delete privileges to a client that can reach production. Run Wipe against DEV/TEST servers only.
• Give API clients a short token lifetime, because most tools don't invalidate their tokens.
• Rotate client secrets on a regular schedule.
• Require FileVault on any Mac that runs the tool.
• Save Wipe backups and other exports to an approved, access-controlled location, and delete them when they're no longer needed.
• If you use a firewall allow-list, allow only your Jamf Pro servers, the licence server and the download hosts your Jamf Pro server uses.