#14. Security Considerations

• HTTPS is required for all HTTP addons except localhost/LAN addresses used for local development.
• CORS: addons intended for web-based hosts should send Access-Control-Allow-Origin for their expected origins.
• Token leakage: because url-token auth puts the credential in the URL, authors should treat tokens as bearer secrets - short expirable tokens for shareable/demo links, long-lived ones only for private, non-logged contexts. Hosts must not log full addon URLs in crash reports/analytics.
• Sandboxing compiled modules is the single most important host-side security control in this spec - a module is arbitrary code, not a data payload, and must never run with ambient access to the host's storage, other addons' credentials, or the filesystem beyond what it's explicitly given.
• Allowlist spoofing: clients.allowlist is a courtesy contract between author and well-behaved hosts, not a cryptographic guarantee (nothing stops a hostile client from lying about its clientId). Authors who need a hard guarantee should combine it with auth (§6), not rely on clients alone.
• Never invent data: resolve and resolve-isrc responses are trusted blindly by hosts once returned - an addon that guesses instead of returning null actively harms the user's queue/library integrity.
• DRM license endpoints (drm.licenseUrl) are a separate trust boundary from addon auth (§6) - a host should not forward its own addon credentials to a license server unless the addon explicitly says to via drm.headers, and should never cache license responses across users.