Security

Last updated 2026-07-06

People trust Avieros with business data and civic questions, and that trust is a responsibility before it is a feature. This page describes our security posture in concrete terms — what is actually in place, how it is enforced, and, just as deliberately, what we do not claim yet.

1. Encryption & transport security

• TLS everywhere. All Avieros surfaces are served exclusively over HTTPS, with HTTP Strict Transport Security (long max-age, including subdomains, preload) so browsers refuse to connect insecurely.
• Hardened response headers. Production responses ship a Content-Security-Policy, X-Content-Type-Options: nosniff, clickjacking protection (frame-ancestors 'none' / X-Frame-Options: DENY), a strict Referrer-Policy, and a Permissions-Policy that disables camera, microphone, geolocation, payment, and USB access by default. You can verify these yourself from any Avieros page with your browser’s developer tools.
• This site runs no code in your browser. The Trust Center itself is static HTML and CSS — no JavaScript, no cookies, no analytics, no third-party requests except fonts.

2. Data access & tenant isolation

Avieros business surfaces are multi-tenant: many businesses, one platform. Isolation between them is enforced at the database layer, not just in application code:

• Row-level security (RLS) is enabled on production database tables, so a query can only return rows the authenticated caller is entitled to — membership-scoped, never a hardcoded list.
• Automated isolation gates run before merges. Our release pipeline includes dedicated cross-tenant checks — an RLS policy audit and tenant-isolation test harnesses that verify a member of business A cannot read business B’s data — and a change that fails them does not ship.
• Fail closed. When an access check cannot be completed, the request is denied. An error is never treated as permission.

3. Secrets handling

• Secrets never live in the codebase. API keys and credentials are kept in environment secret stores, never committed.
• An automated secret scan gates every change. A scanner that looks for committed keys, tokens, and service credentials runs as part of our standard proof pipeline before deploys.
• Rotation on exposure. If a credential is ever suspected exposed — in code, logs, or screenshots — the standing rule is immediate rotation, not assessment first.
• Least privilege. Public clients use limited-scope keys; administrative keys are restricted to server-side automation and are never shipped to a browser — and an automated check rejects any change that would.

4. Proof-before-claim engineering

Most security failures we have seen in the wild start as process failures: something was believed deployed, fixed, or isolated, but never verified. Avieros engineering runs on written rules designed against exactly that:

• “Local green” is not production. A change counts as live only after the deployed URL is independently reachable and behaving — verified against the real production domain, not a preview.
• Proof receipts. Deployments and verifications are recorded as receipts in the repository, so “done” claims are auditable after the fact.
• Two-person verification. A module may not be marked done by the same thread that built it; it requires an independent verification pass first.
• A five-dimension readiness gate. Pages must pass automated checks for functionality, brand consistency, accessibility, tenant-isolation security, and honesty (no fabricated success states) before they may be called done. This site is registered in that gate.

5. What we do not claim

6. Report a vulnerability

If you believe you have found a security issue in any Avieros property, email privacy@avieros.com with the subject line SECURITY. Please include steps to reproduce. Good-faith research conducted without harming user data will not be met with legal threats.