Different platforms. The same need for clear scope.

Choose the role before the operating system

A device can run the scanner, host the API, or act as a client. Those are different roles with different requirements. A Windows desktop used to review a report does not establish that the scanner runs natively on Windows. A mobile application can call an API whose security decisions live on a remote server.

This is a planning map, not an ApiScanner.com compatibility claim. Check the selected third-party tool's current runtime, processor architecture, supported authentication, and documented scan behavior.

Linux, macOS, and Windows

For a Linux runner, define package or container ownership, network access, and report permissions. Avoid broad filesystem permissions as a shortcut around configuration errors. For a macOS setup, check host-to-container networking and mounted-directory behavior. For Windows, document the selected shell, path conventions, and native or virtualized runtime.

Keep application and scanner revisions in the run record. A machine that successfully starts the tool may still be using an incorrect target or test identity. See the self-hosted workflow and CLI runbook guide for repeatability checks.

Android, iOS, and iPhone clients

Separate the mobile client from the API it calls. An authorized server-side assessment can help review API permissions; it does not establish the security of the mobile app, device storage, or operating system. Identify exactly which boundary the evidence describes.

Use synthetic accounts and records in a supported staging environment. Do not capture another person's messages, activity history, or location information simply to obtain realistic traffic. When no approved test environment exists, document the limitation and focus on supported configuration review.

Django, WordPress, and web applications

Map route ownership, authentication, and object permissions independently of the server operating system. Framework protections depend on how the application uses them. A route listing is not proof that each method and role receives the right behavior.

The web application guide separates Django, WordPress REST routes, and LAMP server concerns. Use the framework documentation that matches your deployment and retest custom permission rules after relevant changes.

Cloud, hardware, and home networks

Cloud environments require exact scope across accounts, services, and vendors. A Raspberry Pi has specific resource and architecture constraints. A home appliance or wearable may depend on a vendor-operated API you are not authorized to test.

Follow the cloud assessment guide or the hardware and IoT guide to map those boundaries. Keep APIs, firmware, radios, and physical devices as separate assessment claims. Owning one component does not establish authority over the whole ecosystem.

Primary references

Read the documentation that matches your tool, framework, and deployment. These sources provide context; they do not establish coverage of your environment.

• OWASP Internet of Things
• Django 5.2 security documentation
• WordPress custom REST endpoints