Security Research Program
At Arcade, security is fundamental to our mission of building safe and reliable . We recognize that the security research community plays a valuable role in identifying potential vulnerabilities.
Scope
Our program covers security issues in:
- Arcade production services and APIs
- authentication and authorization mechanisms
- Data handling and storage systems
- Published open-source components
What we’re looking for
We’re interested in reports about:
- Authentication or authorization bypasses
- Data exposure or leakage
- Injection vulnerabilities
- Logic flaws affecting behavior
- Issues that could compromise user data or integrity
A finding that shows one reading or changing another tenant’s tokens, secrets, or data is in scope. Send that.
Reporting process
Please email our security team with:
- A clear description of the issue
- Steps to reproduce
- Potential impact assessment
- Any relevant proof-of-concept code (please be responsible)
Leave other Arcade addresses off the message. We’ll acknowledge receipt within 72 hours and aim to provide an initial assessment within one week.
Guidelines
- Please allow us reasonable time to address issues before public disclosure
- Avoid automated scanning that could impact service availability
- Do not access or modify other ’ data
- Keep any discovered vulnerabilities confidential until resolved
Recognition
While we’re a small team with limited resources, we appreciate the effort researchers put into improving our security. We’ll credit researchers (with permission) in our security updates and may provide modest rewards for significant findings on a case-by-case basis.
For questions about this program, please contact our security team.
Common questions
These are the questions we answer most often: mail authentication, DNS, and reports about OAuth that describe the Arcade Cloud data model. They describe Arcade Cloud. A self-hosted is the operator’s deployment, with that operator’s own keys and network.
The sender policy framework record ends in soft fail
The SPF record for arcade.dev ends in ~all. That qualifier is SoftFail. Receivers treat a SoftFail result as an unauthorized sender. Neutral is a different qualifier, ?all.
DMARC for the domain is p=reject. Receivers reject mail that claims to be from arcade.dev and fails alignment, with the record ending in ~all or in -all. Valimail manages the record and publishes ~all on purpose.
A report that asks us to replace ~all with -all describes the record we publish.
An unsigned DNS zone is an accepted configuration
The arcade.dev zone has no DNSSEC signature. A report that shows missing RRSIG records describes that configuration. We treat it as a DNS choice, separate from a product vulnerability.
A missing CAA record is hardening
CAA records are optional. A report that shows the record is absent, and stops there, has no mis-issued certificate to investigate. We monitor for unexpected certificate issuance, and we have worked with our DNS provider on CAA as hardening.
Auth error pages come from the identity vendor
Ory serves the error page on auth.arcade.dev. Arcade uses Ory for login. Report content reflected on that page through Ory’s security process .
Public discovery documents stay public
These surfaces are public on purpose:
auth.arcade.dev/.well-known/openid-configurationis the OpenID discovery document. Arcade leaves dynamic client registration off.- Signup at
account.arcade.devis how a customer creates an Arcade . - Hostnames under
server.arcade.devare per-deployment servers.
A scanner that lists those URLs has found the public surface.
A project API key is an administrator credential
Arcade Cloud isolates data by and by project. A is the trust boundary. Everyone with membership in a project, or with one of its , shares that project’s , brokered tokens, and secrets, and can start authorization for those users. Invite people you trust, and join projects you trust.
A authenticates as the administrator of that one project. Calls made with the key can start authorization and can read tokens for of that project. Keep the key on a server. A report that uses your own project key to read your own project’s tokens is that role, working as designed.
A user id belongs to one project
Arcade stores user_id as an opaque string on the . An email address is a common choice, and any string is valid. The same string in a second project names a different . ada@example.com in your project has no link to ada@example.com in another .
When a sends a user_id, Arcade stores that value as the administrator’s name for a inside that project. The key can address users in its own project.
Completing a flow stays in the project that started it
Authorization completion checks two facts:
- The API key belongs to the that started the flow.
- The
user_idmatches the id from the start of the flow.
The user id stays off the browser redirect. A flow started in one finishes with that project’s key.
A custom auth provider replaces the platform provider for your tenant
You can add an whose id matches a platform provider, such as google. That provider then handles authorization for your , and the authorize URL carries your client id. The identity provider still enforces its own rules, including ownership of the redirect URI.
Running that client through Arcade matches running the client on your own server. The consent screen is your OAuth client.
An administrator who saves a broken can take that ’s catalog offline. The outage stays inside the tenant. Administrators can change providers.
Default OAuth apps follow project membership
Arcade’s default OAuth apps work with the Arcade user verifier. The verifier asks the end user to sign in to an Arcade that is a member of the . Membership means the project may act for that account on connectors that use the default app.
A token that shows up in a second project means that Arcade joined the second . A project the account never joined cannot name them and read their mailbox.
For a multi- production app, add your own OAuth client and a custom user verifier. Default apps fit development and single- use.
We described a related consent-binding issue, and the control Arcade ships for it, in Confused deputy attacks on OAuth .
Secret names are public
Platform secret names are public. Toolkit pages list the secret each expects, so you can replace a default with your own value. You should expect to see the name.
A response that returns secret values, or another ’s secret material, is a different finding. Send that.
Health-check tokens authenticate the health check
Worker health checks use a throwaway credential minted for that check. Steady-state calls to a deployed worker use a secret for that deployment. A token taken from a health check does not authenticate those calls.
Show us that token succeeding on a real worker request, or reaching another ’s data, and we will investigate that evidence.
Plan limits are billing
Arcade bills premium on the plan the is on.
A race that lets one pass a plan quota is a metering bug. We look at those, and we file them with billing, apart from access to another ’s data. Billing-limit bypasses sit outside the reward side of this program.
Retired hosts and archived examples
A hostname we have retired, that can still change content or hold customer data, is worth a report. Name the host and what changed. We have removed retired properties after reports like that.
Archived example repositories are samples. A static scan of an archived repo, with no impact on Arcade Cloud, is outside this program.
Files on a developer laptop
The Arcade CLI can write a credentials file on the machine where you run it. That file is local developer state. Arcade Cloud keeps brokered tokens in Arcade Cloud. A local file-permission finding needs a cloud impact, or a default that exposes another person’s data, before it fits this program.