Current controls
Perigee's current application includes the following safeguards:
- Encrypted transport: production traffic is served over HTTPS, with HSTS and browser security headers applied by the application.
- Authentication boundary: account authentication is handled by Firebase Authentication. Server account routes validate a Firebase ID token before accessing user-specific state.
- Credential storage: Perigee API keys and OAuth tokens are generated from cryptographically random values and stored as SHA-256 hashes rather than raw secrets. Newly created API keys are displayed once.
- Scoped access: key, billing, saved-station, alert, and email preference operations check authenticated ownership on the server. Firestore is accessed through server-side Admin SDK paths rather than a public client database interface.
- Billing integrity: Stripe hosts payment entry. Perigee verifies Stripe webhook signatures and records processed event IDs so repeat deliveries do not apply the same subscription transition twice.
- Abuse controls: public and authenticated API/MCP traffic is rate-limited, credential usage is attributable, input schemas reject invalid shapes, and sensitive account routes are not cacheable.
- Browser isolation: the application sends a Content Security Policy, anti-framing rules, content-type protections, a strict referrer policy, and a restricted Permissions Policy. The policy permits only the current Firebase, Google sign-in, Stripe, Vercel Analytics, and OpenFreeMap browser dependencies.
- Secret separation: server credentials are configured as deployment environment secrets. Public Firebase web configuration is separated from Firebase Admin, Stripe, webhook, email, and cron secrets.
Protecting your account and integration
- Use a unique password and protect the connected email or Google account.
- Never put API keys, OAuth tokens, Firebase Admin credentials, Stripe secrets, or webhook secrets in browser code, source control, public logs, screenshots, prompts, or support email.
- Use different credentials by application or environment where available, limit who can access them, and revoke them promptly after exposure.
- Treat results, webhooks, and downstream inputs as untrusted. Validate schemas, bound retries and concurrency, and preserve missing-data states.
- Do not use Perigee as a navigation or safety control. Security cannot turn delayed or incomplete provider data into official operational advice.
Report a vulnerability
Email ryandcardin@gmail.com with the subject Perigee security report. Plain text is accepted; Perigee does not currently publish a PGP key. Include:
- the affected URL, endpoint, feature, or repository path;
- a concise impact statement and the prerequisites;
- reproducible steps using the smallest safe proof of concept;
- approximate timestamps, request IDs, and browser/client details; and
- a safe way to contact you for clarification.
Do not send passwords, full payment-card numbers, live API keys, session tokens, or personal data belonging to someone else. If a credential is relevant, revoke it first and provide only its non-secret prefix.
Good-faith research scope
Research should use accounts and data you own or have explicit permission to test, minimize requests, and stop once you have enough evidence to report the issue. The following are out of scope unless Cardin LLC gives written authorization first:
- denial of service, load testing, or resource exhaustion;
- social engineering, phishing, physical access, or employee targeting;
- accessing, changing, retaining, or disclosing another person's data;
- automated scanning that creates material traffic or provider cost;
- testing Stripe, Google, Firebase, Vercel, NOAA, NWS, Resend, or another third party instead of Perigee-owned behavior; and
- public disclosure before Cardin LLC has had a reasonable opportunity to understand and reduce a credible risk.
This page is a reporting policy, not authorization to violate law or a promise of immunity, payment, reward, or a particular remediation timeline. Cardin LLC will evaluate reports based on demonstrated impact and available capacity.
Machine-readable contact
Automated tools can use /.well-known/security.txt. Its expiration date is intentionally finite so stale contact instructions are not presented indefinitely.
Incidents and service state
Point-in-time public checks and provider limitations are available on the status page. A successful status check does not prove that every station, account, provider, delivery, or billing workflow is healthy. If you suspect unauthorized account activity, revoke exposed credentials and contact us promptly.