0 Hour Studio · Different Hunger Media, LLC
Security
How the 0HR platform protects client data, what we verify continuously, and — just as importantly — which assurances we cannot yet offer. Written for security reviewers, procurement, and partners performing vendor diligence.
Assessed 2 September 2026Scope 0hr.app platformBasis Self-assessed, machine-verified
Continuously verified — generated from the running system, not maintained by hand
116
Endpoints under policy
0
Without a reviewed access decision
27/27
Tables with row-level security
5/5
Browser hardening headers active
How access is decided
Every endpoint resolves through one shared authorisation module. There is no second implementation to drift out of step, which is the failure mode this design exists to remove.
Default deny
An endpoint is unreachable unless it carries an authorisation check or is listed in a policy file with a typed justification. Public access is an exception that has to be argued for and recorded.
Enforced
Fails closed
If a credential or signing key is absent, authorisation is refused rather than skipped. Missing configuration can never widen access.
Enforced
Scoped to one client
Workspaces are isolated. Authorisation is evaluated per brand against workspace ownership, so a session for one client cannot read another's records.
Enforced
Sessions, not passwords
Access issues a signed, expiring, workspace-scoped token verified by HMAC-SHA256 in constant time. The password is proven once and never stored in the browser.
Enforced
Server-to-server
Internal service calls authenticate with a dedicated bearer token, separate from any human credential and independently revocable.
Enforced
How data is protected
Controls apply at the database, the application, and the response.
Row-level security
All 27 application tables enforce row-level security in PostgreSQL. The browser-facing database key resolves zero rows on every table; data is reachable only through server code that has already authorised the caller.
Enforced
Secret redaction
Responses pass through a filter that strips credential-shaped keys and values before serialisation — matching on shape rather than a list of known names, so a newly added secret is protected the day it is written. It applies even to authorised readers.
Enforced
Encryption
TLS 1.2+ in transit with HTTP Strict Transport Security and automatic upgrade from plaintext. AES-256 at rest across the database and object storage via our infrastructure providers.
Enforced
Credential storage
Third-party keys live in an encrypted environment store, scoped per deployment environment. No secret is present in the browser bundle or in version control.
Enforced
Least-privilege reads
Endpoints return an explicit field allowlist rather than whole records, so adding a column to a table does not silently widen an existing response.
Enforced
Payments
We are not a payment processor and hold no funds. Every rail is designed so that sensitive instruments never reach our infrastructure.
Card data
Cards are entered directly into processor-hosted fields. Card numbers, expiry and security codes never reach our servers, logs or database — the scope reduction Stripe documents as SAQ A. We store only the processor's identifiers.
Enforced
Bank details
Wire instructions are served server-side only and released against an issued invoice number rather than published — the control that makes wire-redirection fraud materially harder.
Enforced
Digital assets
Non-custodial. Buyers transfer directly to a self-custody address; we never hold customer funds, and no private key exists anywhere in the platform.
Enforced
Webhook integrity
Inbound processor callbacks are rejected unless their cryptographic signature verifies, so a payment cannot be forged by posting to a public URL.
Enforced
Security as a build gate
The control we would most want to see in a vendor, so it is the one we lead with: our access policy is executable, and violating it stops a release.
Automated audit
A generator walks every endpoint, detects whether a genuine authorisation primitive is present, and reconciles it against the written policy. It matches on real code — a comment claiming a route is safe does not satisfy it.
Enforced
Release blocking
A new endpoint that is neither authorised nor explicitly declared public fails the build. Access control cannot be forgotten; it has to be decided.
Enforced
Evidence on demand
The figures on this page regenerate from the live system, so a control that regresses is visible in the next report rather than at the next incident.
Enforced
Isolated environments
Production, preview and local builds carry separate credentials. Development cannot transact against live payment or client systems.
Enforced
Browser hardening
Response headers on every route, verifiable from outside by any reviewer.
| Header | Setting | Protects against |
|---|
| Strict-Transport-Security | max-age 2 years, subdomains | Protocol downgrade, cookie interception |
| Content-Security-Policy | frame-ancestors allowlist | Clickjacking, UI redress |
| X-Content-Type-Options | nosniff | MIME confusion attacks |
| Referrer-Policy | strict-origin-when-cross-origin | URL and identifier leakage |
| Permissions-Policy | camera, mic, geolocation denied | Unexpected device access |
Server technology headers are suppressed. We publish no version information that would help an attacker match a known vulnerability to our stack.
Subprocessors
Third parties that may process client data on our behalf.
| Provider | Function | Data handled |
|---|
| Vercel | Application hosting, edge network | Request metadata, application logs |
| Supabase | Database, authentication, file storage | Client records, contacts, documents |
| Stripe | Card and wallet payments | Cardholder and billing data (held by Stripe) |
| Strike | Bitcoin settlement | Invoice and transaction references |
| Twilio | Voice and SMS | Phone numbers, call and message records |
| Resend | Transactional email | Recipient addresses, message content |
| Google Workspace | Documents, calendar, mail | Deliverables and correspondence |
Engagements can be delivered against the client’s own accounts for any of the above. Where a client keeps their own payment, email or data infrastructure, that data never enters ours — a property of how engagements are structured, not an exception.
What we do not yet claim
A reviewer who finds one inflated claim discounts the whole document, so these are stated plainly. Each is on the roadmap; none is represented as complete.
- No SOC 2 or ISO 27001 certification. The controls below are self-assessed and machine-verified, not attested by a third-party auditor. We say so in any questionnaire.
- No independent penetration test yet. Our assessment is internal. We welcome, and will cooperate fully with, a prospect's own security review.
- No HIPAA program or Business Associate Agreement. We work with healthcare-adjacent operators, but we do not currently offer a BAA and do not hold ourselves out as HIPAA-compliant.
- Credential rotation is manual. Keys are rotated on a documented schedule and on any suspicion of exposure, but rotation is not yet automated.
- Centralised audit logging is partial. Application events are recorded; a consolidated security event log with alerting is planned, not shipped.
- No formal bug bounty. Reports are handled directly and acknowledged; there is no funded program.
Reporting a vulnerability
Email security@differenthunger.com with steps to reproduce. We acknowledge within one business day, and we will not pursue action against good-faith researchers who report privately, avoid privacy violations, and give us reasonable time to remediate.