Security at YourBot

1. Marketplace Plugin Sandbox

On our servers, marketplace plugins run only inside Docker containers of their own, kept apart from other plugins and from YourBot's own services. A plugin's containers serve every server that installs it rather than one server each. While a plugin runs:

• No direct network access. Its container starts with networking turned off. To reach the internet, a plugin has to ask YourBot to make HTTP requests or hold WebSocket connections for it, and it can do that for your server only while that permission is on for your server. YourBot checks each destination the plugin names and refuses private network and cloud metadata addresses, does not follow redirects on HTTP requests and limits how many requests each plugin can make on each server. One copy of a plugin serves every server that installs it, so if another server allows those requests, the plugin could still send out data it received from yours.
• A read-only filesystem. Inside its container a plugin can write only to small, size-capped temporary storage that is erased when the container stops. Anything it keeps longer is stored through the platform API.
• No root. Plugin code runs as an unprivileged user (uid 65534) with all Linux capabilities removed, setuid privilege gains blocked and system calls limited to an allowlist by a seccomp profile.
• Hard limits. Every plugin container has fixed limits on memory, CPU and the number of processes. A plugin that goes over its memory limit is stopped, and one that uses too much CPU is slowed down.
• No YourBot credentials. A plugin container starts with no YourBot credentials, no connection details for YourBot's systems and no access to YourBot's files. It never receives your bot token: when a plugin sends a message or assigns a role, YourBot makes that Discord call for it after checking the plugin's permissions on your server.
• Automatic shut-off. A plugin that crashes 5 times within 5 minutes is quarantined and turned off on every server that uses it, and each server's owners and managers get a notice in the dashboard.
• Plugin dashboard pages. If a plugin comes with its own custom dashboard page, that page runs in your browser inside a frame served from a separate domain, sandbox.yourbot.gg. Its security policy stops the page's scripts from opening fetch, XHR or WebSocket connections.

YourBot builds each plugin's container image from its own fixed template. A plugin's Python dependencies are installed only as prebuilt packages from PyPI, so no code from the plugin or its dependencies runs while the image is built.

2. What a Plugin Can Reach on Your Server

• You choose its permissions. When you install a plugin from its marketplace page you see every permission it asks for and can switch any of them off. Reading message content starts switched off. A plugin can use only the permissions left on for your server, and you can change them later. A plugin you buy is installed automatically once payment goes through, with every permission it asks for switched on, so review its permissions after you buy it. Renewal payments never switch a plugin back on that you switched off and never change its permissions.
• Message content stays out unless you allow it. Unless reading message content is switched on for a plugin, message text, embeds and attachments are removed from the message events it receives, and message text is blanked when it reads channel history. Buttons, menus and forms work differently: a click or a form submission goes only to the plugin that created that button, menu or form. Clicks on buttons and menus posted before this protection existed may still reach every marketplace plugin on your server, but text typed into a form never reaches a plugin that did not create it.
• Updates that need new permissions wait. Automatic updates skip any new version that asks for a permission your server has not approved. An owner or manager has to approve it first.
• Data kept apart for each server. A plugin reaches YourBot data only through the platform API, and only for servers that have installed it. What the platform stores for a plugin (key-value data, database tables and per-server secrets) is kept separate for each server and each plugin. When a plugin asks YourBot to act on Discord, YourBot refuses if the channel, webhook or interaction belongs to another server. One running copy of a plugin serves every server it is installed on, so what it does with the data it receives is up to the plugin's own code.
• A separate database for plugin tables. Tables a plugin creates with its SQL storage live in a separate database from YourBot's own data. Its queries run under a database role for that plugin inside a schema for your server. Each query is stopped after 5 seconds.

3. How Plugins Reach the Marketplace

• Automated checks on every version. Every upload is checked automatically before it is stored, and marketplace submissions are checked again when they are submitted. A submission the checks find errors in is refused, whether or not the developer is trusted.
• Human review. A version from a developer our staff have not marked as trusted is reviewed by a person before it appears in the marketplace, and reviewers cannot approve their own plugins. At approval, the stored package is checked against the fingerprint recorded when it was uploaded and validated again. A reviewer can approve a version that fails validation only by writing down a reason, which is logged.
• Trusted developers. Developers our staff have marked as trusted can publish new plugins and updates without waiting in the review queue, unless the developer marks the plugin's source code as private. Their versions still go through the automated checks, and a version that changes the plugin's dashboard goes to human review first.
• Test builds and private plugins. Without review, a developer can run test builds or their own private plugins only on servers where they have the Owner or Manager role on YourBot.
• Emergency shutdown. Our staff can switch a plugin off on every server at once. One action turns off every install, removes the plugin from marketplace listings, stops anyone buying or installing it from its marketplace page and notifies the developer and the person who installed it on each server. While it is suspended, no server can switch it back on and YourBot does not run it.
• Stored packages. Published plugin packages are kept in a private Google Cloud Storage bucket with public access blocked and file versioning on. The dashboard can write packages to it, and the server that builds and runs plugins can only read them.
• Safe listing pages. The description a developer writes for a marketplace listing is shown with raw HTML turned off and then cleaned against a short list of allowed tags and link types (http, https and mailto), so a listing cannot add its own scripts to the page.

What the Quality chip on a marketplace listing means, and how a plugin earns it, is described on the quality standards page.

4. Discord Permissions

• No Administrator by default. The standard invite link does not ask for Administrator. It asks for the specific permissions the built-in services use, including moderation permissions such as Ban Members, Kick Members and Manage Roles. The AI server builder offers an optional link that grants Administrator, shown only next to the features that need it.
• Privileged intents. The shared YourBot bot always requests two privileged Discord intents: Server Members and Message Content. It requests a third, Presence, only when we have switched it on for the bot and Discord has enabled it for our application. When Presence is on, three built-in services can use it: Analytics (status and activity tracking and member status counter channels), Voice (the {activity} placeholder in room names) and Group Finder (smart pings, which message members who are playing the game a new group is for). Marketplace plugins are never sent presence data. If you run your own custom bot, you decide whether it requests Presence.

5. Bot Tokens and Other Secrets

• Custom bot tokens. When you save a token for your own custom bot, we check it with Discord and then encrypt it at rest with AES-256-GCM, using a key derived for your server from our master key. The dashboard does not show the token again after you save it, and the bot log viewer masks anything shaped like a token.
• The master key. Our production master encryption key is kept in Google Cloud Secret Manager and is never stored in the production database.
• Other server secrets. The Discord webhook links YourBot creates for Social alerts and the prize codes you store for Giveaways are also encrypted with your server's key. A prize code is decrypted only when it is being sent to a winner, and the dashboard shows its label and delivery status but never the code.
• Plugin developer secrets. Secrets a developer stores for a plugin are encrypted at rest with AES-256-GCM. The developer portal never shows a stored value, only its name, length and when it was last updated. A plugin can read only its own secrets, and on each server it gets that server's value or the plugin's default.
• Other stored credentials. A GitHub access token a developer saves for a private repository and the Discord tokens behind Linked Roles are encrypted with AES-256-GCM before they are stored. Disconnecting Linked Roles asks Discord to revoke those tokens and deletes our copies.

6. Where Your Data Lives

• Hosting. The dashboard, the bot and our main database run on Google Cloud in the us-central1 region (Iowa, United States). Database backups are stored in Google Cloud's United States multi-region. Google Cloud encrypts this data at rest. Our status page and the service that suggests answers in YourBot's own support tickets run on a separate server outside Google Cloud.
• A private database. The database has no public internet address and accepts connections only from inside our private Google Cloud network. A standby copy runs in a second zone, backups are taken every day and kept for 14 days and the database can be restored to any point in the last seven days.
• Row-level security. YourBot's services connect to the database with an account that does not own the tables, so the database's row-level security rules apply to them. While you have a server selected in the dashboard, most dashboard requests are bound to that server and the database limits a core set of tables (dashboard access grants, server settings, installed services and plugins, plugin storage and the audit log) to it. The bot, background jobs and the plugin runner are not bound to one server this way and rely on the platform's own checks. This is a second layer behind the dashboard's own permission checks, which remain the main control.
• Payments. When you pay, you enter your card details on pages hosted by Stripe, our payment processor, so your full card number and security code never reach YourBot's servers. From Stripe we keep payment and subscription records, the last four digits of your card, a card fingerprint Stripe provides and the billing name, email and postal code you enter at checkout. Plugin developers set up payouts on Stripe's own hosted pages (Stripe Connect Express), so their bank and identity details are entered with Stripe, not with YourBot.
• When the bot leaves your server. Your services are switched off, and the server's settings and most service data are kept for 30 days in case you add the bot back, then deleted by a daily job. Some records are kept after that, including billing and purchase records, administrative audit log entries (deleted after two years), the account and server IDs used to catch ban evasion (with stored names removed), some usage totals and, still encrypted, any saved custom bot token, Social webhook links and Giveaways prize codes. Deleted data can remain in our daily database backups for up to 14 days.
• Other retention. Daily jobs delete dashboard sign-in records after two years and marketplace plugin crash reports after 90 days. While the Analytics service is on, raw Analytics events are deleted once they pass your server's retention setting (90 days by default). If you turn Analytics off, the events it already recorded stay until you turn it back on or until your server's data is deleted after the bot leaves.
• Website analytics. On our public website, Google Analytics and the X and Reddit ad pixels load only after you click Accept on the cookie banner. If you click Decline, none of them load. We do not show third-party ads in your server or in the dashboard.

The Privacy Policy lists what we collect and why, and how to ask for a copy of your data or have it deleted.

7. Signing In and Dashboard Access

• No YourBot password. You sign in with your Discord account on Discord's own site, so YourBot never sees your Discord password. Sign-in asks Discord only for your basic profile and the list of servers you are in, not your email address. Each sign-in link carries a one-time random value that is checked when you return from Discord.
• Protected sessions. Your session is kept on our servers and encrypted with AES-256-GCM, and your Discord access token stays there. Your browser holds a signed session ID and a signed backup cookie with your Discord user ID and basic profile, which keeps you signed in if our session store is briefly unavailable. Both cookies are marked HttpOnly, Secure and SameSite=Lax, so page scripts cannot read them and they are only sent over HTTPS. A session ends after 24 hours without use.
• Cross-site request protection. Dashboard forms and other POST requests must include a secret token tied to your session, which we check on our side. This stops other websites from submitting forms for you while you are signed in.
• Sign-in rate limits. Sign-in attempts are rate limited per IP address, and the limit is shared across all our dashboard servers.
• Roles. Dashboard access to a server is role based, with three roles: Owner, Manager and Viewer. The server's Discord owner becomes an Owner and can make other people Owners too. Everyone else needs Manager or Viewer access. An Owner can give it on the Access page, with an invite link or automatically to members who hold chosen Discord roles or Discord's Administrator or Manage Server permission. When the bot joins a server for the first time, members with Discord's Administrator permission get Manager access automatically, and an Owner can turn that off on the Access page. By default Managers can change services and plugins but cannot open the custom bot page or change who has access, and Viewers get read-only access. Owners can put an expiry date on Manager and Viewer access and see recent access changes on the Access page.
• Invite links. Access invite links expire after 1 hour, 1 day or 7 days, can be limited to 1, 5 or 25 uses and can be revoked. Our database stores only a hash of each link, so a link is shown once, when you create it.
• Sign-in alerts. If your account signs in on a device and network we have not seen before, you get a YourBot security notification unless you have turned those off. Your account page lists your most recent sign-ins with their time and IP address.
• Your Discord account matters. Because you sign in with Discord, your Discord account's security protects your YourBot access. Turning on two-factor authentication in Discord protects both. A YourBot session that is already open is not ended by changes to your Discord account. It ends after 24 hours without use, and there is no option to sign out your other YourBot sessions.

8. Staff Access

• Two-factor for staff. YourBot staff must pass two-factor authentication, with an authenticator app, a backup code or a passkey, before they can open the staff admin area. A staff member can choose to have a browser remembered for up to 14 days. Staff authenticator secrets are stored encrypted and backup codes are stored only as hashes.
• Fresh checks for sensitive actions. Account bans and suspensions, refunds, staff changes and exporting or erasing a person's data require a fresh two-factor check, which stays valid for 15 minutes in the same browser.
• Read-only support view. Staff can open a read-only view of a server's dashboard to troubleshoot problems. The view blocks changes, cannot open the custom bot page, the Access page or marketplace plugin dashboards, closes after 30 minutes and is recorded in our internal audit log. Opening it requires a two-factor check in the same browser within the previous four hours.
• Staff admin tools. Staff who have passed two-factor authentication can also open an admin page for any server. It shows the server's stored settings, its dashboard access list and its plugins' errors and stored data, and staff can take support actions there, such as restarting a custom bot. Opening a server's settings in these tools is recorded in our internal audit log.
• Staff roles. Staff tools are role based, and a staff role can be given an expiry date. Only YourBot's platform owners can erase a person's data, and each erasure is recorded in a separate log that the erasure does not remove.

9. Infrastructure and Releases

• HTTPS for the website. yourbot.gg is served over HTTPS with automatically renewed Google-managed certificates. Connections use TLS 1.2 or newer. Plain HTTP requests are redirected, and browsers are told to use HTTPS for the site and its subdomains for one year. On Google Cloud, our app servers can be reached from the internet only through our load balancer, and requests for any other host name are refused.
• Browser protections. Our pages tell browsers not to let other sites frame them (except the Group Finder widget, which is built to be embedded), not to guess file types, to send only our site address when you follow a link elsewhere and to keep camera, microphone and location access off.
• A private worker server. Plugins, custom bots and background jobs run on a server with no public IP address. Its firewall accepts connections only from our private network, plus administrator SSH through Google's Identity-Aware Proxy.
• Signed internal requests. Direct web requests between YourBot's own services, apart from health checks, are signed with HMAC-SHA256 and carry a timestamp and a one-time nonce. Unsigned, altered or replayed requests are rejected.
• Secrets management. The keys that protect the platform, including the master encryption key, are stored in Google Secret Manager and are not built into our code or container images. Our worker server receives them from Secret Manager in a file only its root account can read.
• No downloadable cloud keys. Our Google Cloud project has no downloadable service account keys. Our services sign in to Google Cloud with identities that Google manages, so there is no long-lived key file that could leak.
• Verified webhooks. Stripe payment events and GitHub push notifications must carry a valid signature before we act on them.
• Checked outbound fetches. When a service fetches a web address someone typed in, such as a Social RSS feed or a background image for a welcome or stats card, YourBot first checks that the address leads to the public internet and not to our private network or cloud metadata. Social feeds are checked again at every redirect, and card images do not follow redirects.
• Logs stay with us. Our services' logs, traces and metrics stay inside Google Cloud. We do not send them to a third-party monitoring or error-tracking company. Logs kept in Google Cloud Logging are deleted after 30 days.
• Release checks. Each production build of the YourBot application scans the uploaded code for committed credentials, audits its Python dependencies for known vulnerabilities and runs lint checks and the unit test suite, and it stops before anything is deployed if any of them fail. It also stops if the finished container image has a known high or critical vulnerability that has a published fix. The application's Python packages are installed from a lockfile that pins every package to a SHA-256 hash, on a base image pinned to an exact digest.
• Pull request checks. Every pull request into our development and main branches is scanned for committed credentials, has its dependencies audited and must pass lint checks and the unit tests. A change cannot merge into the development branch until those checks pass.
• Monitoring. Automated monitoring checks yourbot.gg every minute. The team is alerted if the website fails those checks, if the service that connects the shared bot to Discord has no running instance for 5 minutes or if our worker server stops reporting.
• Status page. Uptime and incident history are public on the status page.

10. Reporting a Vulnerability

If you think you have found a vulnerability in YourBot, email legal@emberstreamstudio.com with “Security” in the subject line and steps to reproduce. We aim to acknowledge reports within 3 business days. Please do not include real user data or credentials in your report.

Please give us a reasonable window to fix the issue before you disclose it publicly, test only against servers and accounts you own and do not run denial-of-service or destructive tests against the live platform. We will not pursue legal action against good-faith research that follows these rules, avoids accessing, changing or destroying other people's data and goes no further than needed to show the issue exists.

If we determine that a security incident has resulted in unauthorized access to personal data, we will notify affected server administrators or users and any regulators we are required to notify without unreasonable delay, as our Privacy Policy commits.

Machine-readable contact details are published at /.well-known/security.txt.

11. What We Do Not Claim

YourBot has not had an independent third-party security audit and holds no security certifications such as SOC 2 or ISO 27001. Our own team checked every statement on this page against the platform's source code and, where it can be inspected, its production configuration. If an external audit takes place, its scope and date will be published here.