Security

This page tells you how ohapi protects secret values, who can read them, and what the service records. It also tells you what ohapi does not provide.

Encryption

The application encrypts each value before the value goes to the database.
  • ohapi encrypts each secret value with AES-256-GCM in application code. PostgreSQL receives only ciphertext.
  • Each encrypted value carries a key version. ohapi binds the key version into the GCM additional authenticated data. If a person changes the key version, decryption fails.
  • Key rotation keeps old keys available for reads. New writes use the new key. The operator then runs npm run key:rotate to encrypt the remaining values with the new key. After that step, the operator can remove the old key.

Masking and audit

A page does not contain a secret value until a user asks for that value.
  • The queries that list secrets do not select the value. The secrets list on the page does not contain the value, in plain text or encrypted.
  • A reveal is a separate request. That request writes a READ row to the audit log.
  • Each secret create, update, delete, share, and sync writes an audit row. The row records the user, the action, the secret key, the environment, and the time.
  • Users can export the audit log of a project as a CSV file.
  • An admin can stream the audit log to a signed webhook. While the sink is enabled, ohapi sends each row at least one time, for rows up to 7 days old.
  • The retention prune deletes audit rows that are older than 90 days.

Access

Each request resolves to a user and to that user's membership in an organization.
RoleAccess
AdminMembers, roles, integrations, and all secret writes.
MemberRead and write secrets, share, and sync. No member management.
ViewerRead only: reveal, activity, compare, and export.
  • The database stores only the SHA-256 hash of an API key. The server shows the key one time, when it creates the key.
  • A GitHub Actions workflow can exchange its OIDC token for an API key. That key expires after one hour.
  • A service account is a machine identity that belongs to one organization. A service account can hold API keys. It does not sign in with Google.

Dual control

An organization can require approval for changes to production.
  • When an admin turns on dual control, a change to the environment named production waits for approval. The organization sets how many admins must approve (from 1 to 5).
  • The user who requests a change cannot approve that change.
  • An admin can apply a change without the full approval count. That admin must give a reason. ohapi records the reason on the request and audits the change.

Share links

A share link shows one secret one time.
  • A share link shows the value one time. After that view, the link stops working.
  • The recipient must click a button to reveal the value. Link previews in chat and mail tools do not use up the link.

Outbound sync

ohapi can push an environment to Netlify, Vercel, AWS Secrets Manager, GitHub Actions, or a signed webhook.
  • ohapi resolves references before it pushes values. If the environment does not resolve, ohapi pushes nothing.
  • ohapi deletes only the entries that ohapi marked or recorded as its own. The webhook sync does not delete anything.

Sessions

Browser sign-in uses database sessions.
  • A session is a row in the database. It is not a self-contained token.
  • A session expires 7 days after its last extension. Activity extends a session at most one time per day.
  • An operator can end a session. Delete the session row to end the session.

Headers

Each route sends these response headers.
  • X-Frame-Options: DENY and frame-ancestors 'none'. Other sites cannot put ohapi pages in a frame.
  • Strict-Transport-Security. Browsers use HTTPS for later requests.
  • X-Content-Type-Options: nosniff. Browsers do not guess content types.

Limits

ohapi does not provide these items.
  • No SAML sign-in.
  • No SCIM directory sync.
  • An API key is limited to 600 requests per minute. Device login, the GitHub OIDC exchange, and browser actions have no application rate limit.
  • No third-party certification, for example SOC 2.
  • The server holds the encryption key. ohapi is not zero-knowledge and does not use end-to-end encryption.
  • Organization-level actions, for example role changes, do not write audit rows.

Report a vulnerability

Send vulnerability reports by email.

Email security@ohapi.dev. The same contact is in /.well-known/security.txt.