Security Disclosure Policy

How to Report

Email security@apier.no. Plain-text reports are fine. Encrypted submissions (PGP / age) are welcomed if you prefer; ask in your first email and we will publish the corresponding public key on this page before the back-and-forth begins. Include reproduction steps, the affected URL or endpoint, and timestamps if any test traffic should appear in our logs.

In Scope

• Apier.no production surfaces: apier.no and every subdomain we control.
• /v1/ API: authentication, authorization (API key + scope enforcement), rate limiting, RLS, and response shape integrity.
• Sandbox surface: /api/v1/sandbox/* — determinism breaks, secret leakage in mock fixtures, or error-simulator misclassification.
• Discovery files: /llms.txt, /openapi.json, /workflows.json, /.well-known/data-sovereignty, /.well-known/security.txt.

Out of Scope

• Third-party Norwegian government services (Altinn 3, Maskinporten, Brønnøysund, Skatteetaten, NAV) — please report directly to those services. We are happy to forward findings if helpful.
• Subprocessor surfaces (Supabase, Vercel, Resend, Sentry, Plausible) — escalate via their own programs. Apier's configuration of those services IS in scope.
• Findings that require a logged-in user clicking a malicious link from a domain we do not control (no clickjacking-style reports without a concrete impact path).
• Denial-of-service, brute-force, automated scraping, or high-volume traffic against any production endpoint.
• Social engineering of Apier staff, contractors, or customers.

Safe Harbor

Good-faith research conducted within this policy is authorised. We will not pursue civil or criminal action against researchers who: stay within the in-scope surfaces above, avoid privacy violations and disruption of service, do not exfiltrate data beyond the minimum required to demonstrate impact, and report to security@apier.no before public disclosure.

If you are uncertain whether your testing crosses the line, ask first — we would rather scope a test with you than have a useful finding go unreported.

Coordinated Disclosure Window

We follow a 90-day coordinated disclosure window. After you report a valid issue, we ask for up to 90 days to ship a fix before public disclosure. We will keep you updated on progress in writing; if we cannot ship within 90 days we will explain why and propose an extended timeline together. Critical issues affecting customer data will be remediated within 30 days.

Public disclosure happens jointly when both parties agree the fix is shipped and the patch window for affected customers is reasonable. Where appropriate we publish a post-mortem summary on this page after disclosure.

What We Commit To

• 72 hours: acknowledge receipt of your report and confirm the triage owner.
• 7 days: respond with our reproduction status, severity assessment, and a target remediation window.
• 30 days: ship a fix for issues classified Critical (data exfiltration, authentication bypass, RLS escape, integrity break on the audit log or rule evaluation path).
• 90 days: the outer bound of the coordinated disclosure window for any valid finding, with a written exception path if a fix legitimately needs longer.

Recognition

We do not run a paid bug bounty today. We do publish a credits page acknowledging researchers whose reports shipped a fix — opt-in, attribution as you prefer. Pseudonyms welcome. The credits page lives at /security/credits and is updated when a fix lands.

Summary

Email security@apier.no. We acknowledge in 72 hours, respond in 7 days, fix Critical in 30 days, and target a 90-day coordinated disclosure window. Good-faith research is safe-harboured. Machine-readable metadata at /.well-known/security.txt.