Security

The short version

A chatbot on your website is public, so we built Apex assuming someone will try to abuse it: to run up your bill, to make it say things it shouldn't, to read another customer's data, or to take over an account. These are the protections that are on by default. This page describes what the product does today, not aspirations.

Your website and the chat widget

• Runs only on your websites. Each assistant has a public site key, but the chat API accepts it only from the websites you list. Requests from any other origin are refused, and so are browser pre-flight checks, so a copied embed code does nothing elsewhere. The site key is not a secret and gives no access to your account.
• Isolated from your page. The widget renders in a Shadow DOM, so your site's CSS can't break it and it doesn't read your page.
• No cookies, no tracking. The widget sets no cookies and no third-party trackers. Depending on your setting it remembers only the conversation ID, for the tab, for the browser, or not at all.
• Small requests only. Every request is capped at 16 KB, messages are length-limited (1,000 characters by default, adjustable) and a conversation has a maximum length.
• Responses aren't cached and are sent with nosniff, so a browser or CDN can't keep or reinterpret a visitor's chat.

AI safety

• Answers come from your content. The assistant is instructed to answer only with facts found in the pages and text you gave Apex, never to invent prices, policies or contact details, and to say it doesn't know when nothing relevant is found. When it doesn't know, it can offer to hand the conversation to your team.
• Hardened against prompt injection. Visitors' messages, your website's text and your own custom instructions are all passed to the model as data inside clearly marked sections, and the fixed safety rules come first and can't be overridden by them. Text that imitates our section markers is neutralized before it reaches the model. Your own instructions can shape tone and topics but can't switch off grounding or safety.
• No tools, no actions. The assistant can't place orders, change accounts, run code, browse the web or call other systems. The worst a successful manipulation can do is change what one chat says.
• Honest about being an AI, and it won't give definitive medical, legal or financial advice. You can also list topics it must politely decline.
• Isolated per customer. Retrieval searches only the content of the assistant being asked, so one customer's knowledge is never used to answer on another's site.

Abuse and cost protection

• Per-visitor rate limit: 15 messages a minute per visitor by default, adjustable per assistant (1 to 120), plus a per-assistant ceiling, so one person or script can't drain your allowance.
• Daily token budget per assistant (2 million by default, up to 20 million), counted in the database so it survives restarts. When it's used up, the assistant stops answering until the next UTC day instead of running up costs.
• Email can't be used as a spam cannon. Hand-offs are limited per visitor, per assistant and per recipient, per hour and per day. A hand-off address must be confirmed with a code sent to it before we email it, so nobody can point the system at a stranger's inbox.
• Bot checks. Sign-up, log-in, password reset and the waitlist are protected by Cloudflare Turnstile. If the check can't be completed, the request is refused rather than allowed.

Accounts and sign-in

• Passwords are never stored; only a salted scrypt hash (a deliberately slow, memory-hard function) is. Minimum length is 8 characters. Hashes can be strengthened later without locking anyone out.
• Email verification is required before the dashboard opens. Codes are six digits, valid for 15 minutes, stored only as a hash, locked after 5 wrong guesses, and limited in how often they can be requested or guessed in an hour.
• Brute-force protection. Failed log-ins are counted per email, per IP address and per both, and lock further tries for 15 minutes. An unknown email takes as long to reject as a wrong password, and the error message is the same, so the form doesn't reveal which emails have accounts.
• Sessions. The cookie holds a random 256-bit token; our database keeps only its SHA-256 hash, so a database leak doesn't hand out live sessions. The cookie is HttpOnly (scripts can't read it), Secure (HTTPS only) and SameSite=Lax. A session lasts 24 hours, or 30 days if you choose "keep me signed in".
• You stay in control. Changing or resetting your password signs out every other device. You can also sign out all other devices from Settings, and see how many are active.
• Google and GitHub sign-in uses a one-time state value (and PKCE for Google). We accept only an email the provider says is verified, so someone can't claim an address they don't own.
• Security log. Sign-ins, failures, resets and password changes are recorded with time, IP address and browser, so an incident can be investigated.
• Delete your account yourself, after typing your email to confirm. Workspaces that only you belong to are deleted with it.

Protecting your data

• Encryption in transit. Every connection to the website, dashboard and chat API uses HTTPS, with HSTS (two years, including subdomains) so browsers never fall back to plain HTTP. The connection to the database is encrypted and the chat API verifies the database's certificate.
• Every workspace is separate. Dashboard queries are always scoped to the signed-in user's workspace. Every database table has row-level security enabled with no public policies, so the database's public REST interface can't read anything; only our servers, with their own credentials, can.
• Codes and tokens are hashed, not stored in readable form: session tokens, verification and password-reset codes, and hand-off confirmation codes.
• Personal data stays out of logs. Email addresses, phone numbers, card numbers (checked with the Luhn algorithm) and Turkish IBANs are masked before anything is written to our application logs.
• Retention you control. Conversations are deleted automatically after the period you choose (1 to 365 days, 30 by default) and you can delete any of them yourself from the dashboard.
• Training is opt-in. We use your content to improve our own models only if you said yes, and you can change that at any time.
• Hosted in the EU where it matters. The chat API runs in Frankfurt, Germany. See the Privacy Policy for every provider that handles data.

Reading your website safely

When you give Apex a URL, our crawler fetches it on your behalf. Because you type the URL, we treat it as untrusted input so it can't be used to reach our internal network:

• Only http and https on the standard ports (80 and 443); no URLs with embedded credentials.
• Only public addresses. Private, loopback, link-local and reserved ranges are blocked, including their IPv6 and IPv4-mapped forms, and the check is made on the address actually connected to, which defeats DNS-rebinding tricks. Local hostnames such as localhost, .local and .internal are refused.
• Every redirect is re-checked, with at most 5 hops. Time and size are capped, including after decompression, to stop zip bombs.
• It identifies itself as ApexBot and follows the site's robots.txt.

Browser protections

The dashboard and website send the following security headers on every page:

• X-Frame-Options: DENY and frame-ancestors 'none', so the dashboard can't be framed for clickjacking.
• Strict-Transport-Security for two years, including subdomains.
• X-Content-Type-Options: nosniff and a strict referrer policy.
• object-src 'none' and base-uri 'self' in the content security policy.
• A permissions policy that disables camera, microphone and location.

The API only accepts JSON bodies, which a cross-site form can't send without a pre-flight check, and no server identification header is exposed.

How we build and run it

• The code that handles sign-in, retrieval, rate limits, the crawler and data masking has automated tests.
• Secrets (API keys, database credentials) live in the hosting providers' secret stores, not in the code.
• Database changes are versioned migrations that are applied automatically and safely re-run.
• Providers we rely on are listed, with what each one receives, in the Privacy Policy.

What you can do

• List only the websites that should show the assistant, and review the list when your domains change.
• Use a strong, unique password, or Google or GitHub sign-in, and sign out devices you no longer use.
• Keep private information out of the pages and text you give Apex: assume anything there can be quoted to a visitor.
• Set the retention period and daily budget that fit your site, and use a hand-off address you control.
• Tell your visitors how you handle their data, as KVKK and GDPR require.

Report a vulnerability or incident

If you think you've found a weakness, or something looks wrong with your account, email hello@apexbot.eu. Include enough detail to reproduce it. Please give us a reasonable chance to fix it before sharing it publicly, and don't access other people's data, disrupt the service or run automated scans against production. We'll acknowledge your report and keep you updated.

No system is perfectly secure. If a breach affects your data, we'll tell you and the authorities as the law requires. For how we handle personal data, see the Privacy Policy.