Skip to main content

​
Overview

Security for the Boomerang Developer API is a shared responsibility:
  • Boomerang provides secure transport, controlled key management, and monitoring.
  • Integrators are expected to handle credentials, infrastructure, and application logic in a way that aligns with modern security practice.
This page outlines:
  • Transport and TLS expectations
  • How API credentials must be handled and rotated
  • Boomerang-side safeguards
  • Minimum operational practices expected of integrators
For behavioural and acceptable use rules, see the Usage Guidelines. For incident handling, see Incident Response.

​
Transport security (TLS)

All access to the API must use HTTPS:
  • Base gateway: https://gateway.bmrg.app/vN/
  • Plain HTTP is not supported.
Transport guarantees:
  • Connections use modern, industry-standard configurations.
  • Weak or deprecated protocols and cipher suites are not supported and may be removed without notice if they are discovered.
Integrators should:
  • Use up-to-date HTTP client libraries and runtimes.
  • Disable insecure protocol versions and cipher suites in their own environments.
  • Treat TLS configuration as part of their own security posture; Boomerang’s configuration does not replace local hardening.

​
Secrets and credential handling

API tokens are sensitive credentials and must be treated accordingly.

​
Where tokens may be used

Tokens must:
  • Only be used from trusted, server-side environments you control (for example, back-end services, secure job runners).
  • Never be embedded in client-side code or distributed binaries, including:
    • Browser JavaScript
    • Mobile applications
    • Desktop applications distributed to end-users
    • Public scripts or tooling
If a token is exposed to untrusted users or environments, it must be treated as compromised and rotated immediately.

​
Storage expectations

Tokens must:
  • Be stored only in secure secret storage (for example, managed secret managers or encrypted configuration systems).
  • Never be:
    • Hard-coded into source control or configuration files.
    • Shared in chat logs, tickets, screenshots, or documentation.
    • Stored in plaintext in logs, analytics events, or browser storage.
Examples Acceptable:
  • Storing tokens in a managed secret manager and injecting them into the runtime environment of a server-side service.
  • Restricting access to token values to a small, audited operations or platform team.
Not acceptable:
  • Committing tokens to a Git repository (public or private).
  • Copy-pasting tokens into shared chat channels or documents.
  • Using tokens directly from a browser or mobile app.

​
Rotation expectations

In addition to the expiry settings configured in the dashboard, integrators are expected to:
  • Rotate tokens immediately if:
    • Compromise is suspected; or
    • Someone who previously had access to the token no longer should (for example, role change, departure, or vendor change).
  • Prefer shorter token lifetimes for:
    • Internet-exposed services.
    • Environments with broader operator access.
  • Ensure applications can reload new tokens without requiring redeployments that are difficult or slow to execute.
Rotation patterns are described in more detail on the Authentication page.

​
Boomerang-side safeguards

At a high level, Boomerang implements the following security measures for the Developer API:
  • Credential protection
    Token material and key configuration are stored and processed using hardened infrastructure and access control aligned with industry practice.
  • Access control and least privilege
    Operational access to production systems and configuration is restricted to authorised staff using principles.
  • Segregation of environments
    Non-production environments are separated from production. Production data is not routinely used in development or testing environments.
  • Monitoring and anomaly detection
    The platform monitors aggregate usage and key activity to detect patterns consistent with abuse, automated attacks, or misconfiguration.

​
Logging, monitoring, and key analytics

Boomerang logs access to the Developer API to support security and operational stability. This includes:
  • Requests at the gateway level (for example, method, path, status).
  • Token usage metadata (for example, which token was used, when, and for which high-level operation).
  • Limited diagnostic information required to operate and secure the service.
General principles:
  • Sensitive values, such as full token strings, are not intended to be logged in plaintext in operational logs.
  • Logs and analytics are used to:
    • Detect unusual patterns (for example, sudden spikes, unexpected geographies).
    • Investigate incidents and abuse.
    • Inform rate limits and safeguards where necessary.
Integrator expectations:
  • Avoid logging full tokens or other secrets in application or infrastructure logs.
  • Apply masking or truncation for any sensitive fields you choose to log.
  • Log request context in a way that supports your own investigation (for example, X-Request-Id, trace IDs, and relevant identifiers), without including raw secrets.

​
Network controls and IP allowlisting

To reduce exposure, Boomerang supports IP allowlisting on a per-key basis:
  • Allowlists can be configured so that specific tokens only function when calls originate from approved IP addresses or ranges.
  • Keys without configured allowlists rely solely on token secrecy and other controls.
Expectations and recommendations:
  • Where possible, configure IP allowlists for production tokens, restricting them to controlled network locations (for example, VPN, specific VPC egress IPs).
  • Avoid making calls to the Developer API directly from:
    • Developer laptops over arbitrary networks.
    • Uncontrolled on-premises networks without additional safeguards.
IP allowlisting is intended as a defence-in-depth measure; it does not replace correct token handling or application-level security.

​
Zero trust and access patterns

The Developer API is intended to be used within a -aligned model:
  • Every request must present a valid token, regardless of network location.
  • Tokens are scoped per server, and must not be reused across unrelated environments or organisations.
  • Dashboard and token management access should use strong authentication and, where available, multifactor authentication.
Integrators are expected to:
  • Avoid assumptions that any network is “trusted” simply because it is internal.
  • Treat each environment (production, staging, development) as separate from a security perspective, with its own tokens and controls.

​
Operational expectations for integrators

In addition to technical controls, the following operational practices are expected:
  • Minimum logging and monitoring
    • Monitor API usage patterns for each server and key.
    • Alert on unusual spikes, sustained high error rates, or access from unexpected locations.
    • Maintain access logs for administrative actions related to token creation, rotation, and revocation.
  • Change management
    • Treat changes to API integrations (including token rotation, new keys, and new consuming services) as controlled changes.
    • Review and test security-impacting changes before deploying to production.
    • Maintain clear ownership for each integration, including who is responsible for responding to security notifications.
  • Least privilege in your own systems
    • Restrict access to token values to those who genuinely need them.
    • Avoid sharing “shared admin tokens” unnecessarily across multiple teams or systems.
These measures are strongly expected for any integration operating in production or handling user or operationally sensitive data.

​
Relationship to other policies

This page focuses on technical and operational security measures. It should be read together with: Where there is any conflict, the Terms of Service and Privacy Policy prevail over this page.