Legal center

Security and responsible disclosure

How the platform is protected and how to report a vulnerability responsibly.

Overview

This page describes the security measures that exist today in the METAQUANTICS code and explains how to report a vulnerability. It describes only what is implemented. We do not mention certifications (such as ISO 27001 or SOC 2) because we do not claim any.

Brazil's data protection law (LGPD, Law 13.709/2018, art. 46) requires technical and administrative measures to protect personal data. The practices below are our technical part of that obligation.

Practices in place

HTTP headers and content policy

Every response carries one-year HSTS (including subdomains), X-Content-Type-Options: nosniff and a Content Security Policy. The CSP accepts only HTTPS and WSS as network origins, plus data: and blob:, and does not allow eval in production. Pages can only be shown in a frame (iframe) by the same origin (X-Frame-Options: SAMEORIGIN). The exception is the embeddable map, which can only be embedded by the HTTPS origins the operator authorises.

SSRF protection

Routes that take a host, IP or URL from the user and make a request from the server go through a shared guard. It rejects loopback addresses, private networks (RFC 1918), link-local (including the cloud metadata address 169.254.169.254), CGNAT, multicast, documentation ranges and their IPv6 equivalents. For domain names, it resolves the A and AAAA records and rejects the request if any answer falls in a reserved range. Alert webhooks only accept an HTTPS destination on port 443, with no credentials in the URL, and each delivery carries an HMAC-SHA256 signature.

Database with RLS

The application's Postgres tables have Row Level Security (RLS) enabled. Those holding accounts, settings, API keys and alert channels have no policy at all for the public roles (anon and authenticated), which also had every privilege revoked. As a result, only the application server, using a service role, can read or write them.

Passwords, sessions and second factor

Passwords are stored only as scrypt hashes with a random salt, and the comparison runs in constant time. The session lives in an httpOnly, SameSite=Lax cookie, marked Secure in production and signed with HMAC-SHA256. Repeated failed sign-in attempts lead to a temporary lockout. The master administrator account can require a second factor through a TOTP code, compatible with authenticator apps.

Keys, tokens and secrets

Public API keys are stored only as SHA-256 hashes and are shown in full once, when issued. Invitation and password reset links use 32 random bytes, are kept in the database only as hashes and expire: the reset link after 1 hour and the invitation after 7 days. Secrets set through the admin panel are encrypted with AES-256-GCM before reaching the database. AI keys sent by the browser are never accepted.

Admin routes and audit

Admin and scheduled job routes require a bearer secret of at least 32 characters and fail closed: without the secret configured, they answer 503 instead of running unauthenticated. Administrative actions on users, jobs, API keys and connectors go into an append-only audit trail: the database refuses to change or delete those records.

Rate limiting

Routes that take user parameters are limited per client, at 20 requests per minute per route under the default rule, and validate input before using it. When the counter is shared in the database, the client IP is pseudonymised with HMAC-SHA256 before it is stored.

Service worker and live data

The service worker never caches /api responses or non-GET requests: they go straight to the network. It only stores versioned static files and the frame of a few pages, whose HTML carries no live data.

Artificial intelligence and sensitive data

The only cloud AI provider has no data processing agreement. For that reason, the system policy, which configuration cannot loosen, refuses to send it any content classified as sensitive, such as text from Cases, Dossier and OSINT, or questions that match personal data patterns.

Known limitations

We would rather say what is not solved yet:

  • The CSP still allows inline scripts and styles, because the framework's hydration depends on them, and accepts any HTTPS origin. It blocks mixed content, but it is not a strong defence against XSS.
  • The SSRF guard checks the address at DNS resolution time but does not pin the IP on the connection. A DNS rebinding attack with a zero TTL would still have a narrow window.
  • Without a database configured, the rate limit is counted per server instance, not globally.
  • The second factor currently exists only for the master administrator and is optional.

How to report a vulnerability

If you found a security flaw, tell us before disclosing it publicly. Include in your report:

  • the affected URL or route and the type of flaw;
  • the steps to reproduce it, with sample requests where possible;
  • the impact you observed and whether any third-party data was accessed;
  • how you would like to be identified, if you want credit.

Reporting channel not published yet

The dedicated address for security reports has not been published yet. It will appear here and at /.well-known/security.txt. Until then, do not disclose details of the flaw publicly or in open issues.

Scope

In scope:

  • the web application of the official METAQUANTICS instance and its API routes;
  • authentication, access control, injection, SSRF, XSS and data or secret exposure flaws;
  • the service worker client and the key-based public API.

Out of scope:

  • third-party services, such as hosting, database, AI providers and public data sources. Report directly to them;
  • copies of the software hosted by other people;
  • denial of service, load testing and automated scans that degrade the service;
  • social engineering, phishing and physical attacks;
  • the content of the public feeds displayed, which comes from the original sources.

Safe harbour

We will not take legal action against anyone who researches and reports a vulnerability in good faith, provided they follow these rules:

  • use only your own or test accounts, and do not access, change or delete other people's data beyond the minimum needed to demonstrate the flaw;
  • stop and tell us as soon as you find third-party personal data, without keeping or sharing it;
  • do not degrade the service's availability for other users;
  • allow a reasonable time for the fix before any public disclosure.

We do not have a cash bounty programme. If you wish, we will give public credit for the finding after the fix.

What happens next

We confirm receipt, reproduce the flaw, assess its severity and keep you informed until it is fixed. When the flaw involves personal data, we also follow the LGPD obligations on security incidents (art. 48).

Back to top