Security

01 / Approach

Security across the request lifecycle

WorldGate’s security programme focuses on protecting credentials, separating customer records, constraining gateway activity, verifying billing events, and reducing information exposed to browsers and upstream responses. Controls are reviewed as the Service changes.

This page describes current practices, not a warranty that every risk can be eliminated. If you find a weakness, please use the coordinated disclosure process below.

02 / Credentials

Authentication and API keys

• WorldGate API keys are signed with an HMAC-SHA-256 server secret and include a unique key identifier and expiry.
• Signatures are compared using timing-safe verification before an API request is authorised.
• Only the key identifier and operational metadata are registered in the usage database; the complete API key is not stored there.
• Keys can be revoked, are associated with one account, and are checked for expiry and ownership.
• Administrative authentication attempts are rate-limited and can be temporarily blocked after repeated failure.
• Service-role credentials and upstream provider keys are kept server-side and are not sent to the browser.

03 / Data access

Account-level data separation

• Row-level security policies restrict authenticated users to their own account, key, usage, top-up, and related billing records.
• Privileged database operations are isolated in server-side functions; direct execution is revoked from public, anonymous, and ordinary authenticated roles.
• Service-side operations validate the account and key relationship before reserving or recording usage.
• The usage ledger stores model, endpoint, token, cost, status, latency, and timestamp data rather than prompt or model-response text.

Authorised operational access is limited to what is needed to maintain, secure, support, and investigate the Service. Our Privacy Policy explains what information is handled and why.

04 / Gateway

Request and response safeguards

• Requests require a valid signed API key and are limited to supported methods, endpoints, and model identifiers.
• Request size, token estimates, request rate, concurrent requests, and upstream timeouts are constrained to reduce abuse and runaway usage.
• Estimated usage is reserved transactionally before an upstream call and settled after measured usage, reducing race conditions and overspend.
• Provider-specific identifiers are scrubbed from supported responses before they are returned where applicable.
• Upstream redirects are disabled, forwarded headers are allowlisted, and upstream credentials are substituted server-side.
• Errors returned to clients are normalised to avoid exposing internal configuration or provider secrets.

05 / Billing

Payment and balance integrity

• Balance-changing operations use server-side, transaction-aware database functions and idempotent transaction identifiers.
• Top-ups are credited only after the applicable payment flow confirms settlement or an authorised manual review is completed.
• Provider callbacks and settlement operations are authenticated or cryptographically verified where the provider supports it.
• Invoice, amount, currency, status, and settlement details are reconciled before credit is applied.
• Promotional credit and redemption flows include eligibility and reuse controls designed to reduce abuse.

WorldGate does not ask you to send full payment credentials by email. Payment credentials are handled by the selected payment provider under its own security practices.

06 / Web application

Browser and transport protections

• Production traffic is served over HTTPS.
• A restrictive Content Security Policy limits scripts, styles, images, connections, form targets, framing, and object embedding.
• Frame denial, MIME-sniffing protection, referrer controls, cross-origin opener isolation, and a restrictive Permissions Policy are applied at the edge.
• Executable browser dependencies are served from the WorldGate origin rather than loaded from arbitrary third-party CDNs.
• API routes are marked to prevent search indexing.

07 / Providers

Infrastructure and upstream risk

WorldGate uses specialist providers for hosting, edge delivery, database and authentication services, analytics, payments, exchange-rate data, and routed AI models. We minimise the data shared to what is needed for the function, keep privileged credentials server-side, and review provider integration boundaries.

No provider relationship removes all supply-chain risk. Model request content must reach the upstream infrastructure that generates a response. Customers should avoid unnecessary sensitive data, assess model-provider terms, and design fallback behaviour for provider outages.

08 / Customer responsibilities

Security is shared

• Store credentials in a secret manager or protected server environment; never in public repositories or frontend bundles.
• Create separate keys for environments and applications, use descriptive names, review usage, and revoke unused or exposed keys immediately.
• Secure the email account and authentication factors linked to WorldGate.
• Validate and moderate model input and output for your application, especially when tools, code execution, retrieval, or personal data are involved.
• Use least privilege, request limits, budgets, logging, and human review appropriate to your risk.
• Contact us promptly about unexpected usage, account access, payment activity, or suspected compromise.

09 / Disclosure

Report a vulnerability

Email support@worldgateapi.fun with the subject beginning SECURITY:. Please include:

• the affected URL, endpoint, parameter, or component;
• the vulnerability type and potential impact;
• clear reproduction steps or a minimal proof of concept;
• relevant request/response excerpts with credentials and personal data removed;
• whether you accessed or changed any data, and the time of testing; and
• a secure way to contact you and any disclosure deadline you are considering.

Do not include a live API key, password, authentication code, private key, or another person’s personal information. If sensitive evidence is necessary, ask us to arrange an appropriate transfer method first.

10 / Safe harbor

Good-faith research

We will not initiate legal action against research that follows this policy, makes a good-faith effort to avoid harm and privacy violations, uses only the minimum testing necessary, and gives us a reasonable opportunity to investigate and remediate before public disclosure.

This safe harbor does not authorise activity prohibited by law, access to third-party systems, extortion, threats, privacy violations, service disruption, or retaining and using data that does not belong to you. It does not bind third parties. If you are unsure whether a test is appropriate, contact us before proceeding.

11 / Testing scope

What is and is not permitted

In scope

WorldGate-owned production web and API surfaces on worldgateapi.com are in scope when tested through an account and data you control.

Out of scope or prohibited

• third-party services, upstream model providers, payment providers, Supabase, Vercel, Cloudflare, GitHub, or other vendor infrastructure;
• denial of service, volumetric testing, resource exhaustion, spam, or automated scanning that degrades service;
• social engineering, phishing, physical attacks, credential stuffing, or testing employees and users;
• accessing, modifying, downloading, deleting, or retaining another user’s data;
• creating fraudulent payments, chargebacks, or financial loss;
• public disclosure before we have had a reasonable opportunity to investigate and fix a confirmed issue; and
• reports limited to missing best-practice headers, self-XSS, clickjacking on pages that cannot perform sensitive actions, version disclosure, or automated scanner output without demonstrated impact.

Use the smallest possible number of requests. Stop immediately if you encounter another person’s data or observe instability, and report what happened.

12 / Response

What to expect

We aim to acknowledge a well-formed security report within three business days, provide an initial assessment or request for more information within ten business days, and keep the reporter informed when a confirmed issue requires longer remediation. Complex reports and third-party dependencies may take more time.

Please allow coordinated remediation before disclosure. We do not currently operate a guaranteed paid bounty programme, but we value clear, responsible reports and may recognise helpful researchers at our discretion.