Security at nomosly

Overview

nomosly runs entirely on AWS managed services in US-East-1. We minimize the data we collect, encrypt everything in transit and at rest, and isolate customer data at the database level. We do not retain image bytes after processing and we do not write request bodies to logs.

Encryption in transit

All traffic to the API and console is served over HTTPS with TLS 1.2 or higher. HTTP requests are redirected to HTTPS. The marketing site is also HTTPS-only. Internal calls between our compute, data, and processing layers traverse our cloud provider's private backbone and are encrypted in transit.

Encryption at rest

All managed datastores (users, API keys, usage records) are encrypted at rest with AES-256 using cloud-provider-managed keys. Log groups are encrypted by the cloud provider. We do not store customer-submitted images on disk; image bytes exist only in memory during the request lifecycle.

Authentication

Console access is delegated to Auth0: we never see or store user passwords. The console establishes a session cookie scoped to /dashboard, marked HTTP-only and Secure.

API authentication uses customer-issued API keys passed in the x-api-key header. Keys are validated server-side against a constant-time hash comparison; the response time does not leak whether the key id or the secret was wrong.

API key handling

• Keys have the format <key_id>.<secret> where the secret is 32 random bytes from crypto.randomBytes
• The plaintext secret is shown to you once at creation and never stored. We store only the SHA-256 hash
• Keys can be scoped to a subset of operations (face compare, face detect, label detect, text detect) at creation time
• Keys can be created with an expiration date and revoked instantly from the console
• A revoked key fails authentication on the next request and cannot be reactivated

Webhook integrity

Webhooks from our payment processor are verified using HMAC-SHA256 with a shared secret. The signature comparison is done with crypto.timingSafeEqual on raw bytes (constant-time, no length leak). Signature verification happens before JSON parsing, so a malformed or unsigned payload never reaches our handlers.

Rate limiting

Two layers protect the API from abuse and runaway costs:

• Service-wide: 20 requests/second sustained, 50 burst, enforced at the API edge
• Per API key: 100,000 requests per UTC day, enforced by an atomic counter at the data layer. Exceeding the quota returns a 429 with a clear message including the limit, current usage, and reset time

These limits protect you from accidental loops in your code and from the worst-case impact of a leaked key.

Logging & PII

API access logs include request metadata (timestamp, source IP, method, path, status). Request and response bodies are explicitly excluded from logging. Application code does not log image bytes, API keys, or webhook payloads.

Log groups are retained for 30 days, then automatically deleted.

Tenant isolation

Every record in our datastores is partitioned by user id. Application code enforces a cross-tenant guard: when looking up an API key by id, we additionally verify the key's userId matches the requesting user before acting. This guard is covered by automated tests.

IAM & infrastructure

Each compute function runs with a dedicated role granting only the minimum permissions it needs:

• Vision endpoints: read-only on users, scoped read/write on API keys (counter + lastUsed) and usage records, plus the specific image-processing action they invoke
• Billing read endpoints: read-only on users, no image-processing access
• Webhook handler: read/write on users only
• Admin endpoints: bounded to their resource type

The infrastructure is defined in code and reviewed on every change. Changes to permissions appear in the deployment diff before being applied.

Backups & recovery

All managed datastores have point-in-time recovery enabled, allowing restoration to any second within the last 35 days. Datastores use a retain-on-delete policy: an accidental infrastructure teardown cannot drop them.

Subprocessors

We rely on a small set of vetted third-party providers for cloud infrastructure, identity, and billing. The full list, including the data each one processes, is maintained in our Privacy Policy.

Reporting a vulnerability

If you discover a security issue, please report it to support@nomosly.com with [SECURITY] in the subject. We aim to acknowledge within 1 business day and to keep you informed through remediation. Please give us a reasonable window to fix the issue before public disclosure. We do not pursue legal action against good-faith security researchers.