Security & data handling - Phosra Developer Docs

Phosra handles children’s data, so the bar is higher than “we take security seriously.” This page is the developer-facing reference: exactly which fields each object stores, how long they live, how to erase them against a real endpoint you can call right now, how data is encrypted, where it lives, who the subprocessors are, and how to report a vulnerability.

One source of truth. The authoritative, always-current security posture — subprocessor list, DPA, SOC 2 status, incident history — lives at the Phosra Trust Center. This page mirrors it for developers and adds the runnable erasure flow. Where a claim is forward-looking rather than code-verifiable today, it is tagged policy preview.

Data minimization — collect the least that works

Phosra is a control plane for parental-controls policy, not a data lake. It stores the metadata needed to compile and enforce a policy, and nothing it does not need. The core object model is the whole surface — there is no hidden telemetry object.

What each object stores

Family — the household root

Field	Classification	Why it’s collected
`id`	Identifier	Primary key.
`name`	Low-sensitivity	Household display name (e.g. “The Rivera Family”). Free-text — not validated as a legal name.
`created_at` / `updated_at`	Metadata	Lifecycle timestamps.

No address, no payment data, no location. A family is a container.

FamilyMember — a guardian on the account

Field	Classification	Why it’s collected
`id`	Identifier	Primary key.
`family_id` / `user_id`	Identifier	Links a guardian’s authenticated user to the household.
`role`	Metadata	`owner` · `parent` · `guardian` — drives who may change or delete what.
`joined_at`	Metadata	Audit timestamp.

The parent’s login identity (email) is held by the auth provider (WorkOS), stored hashed, and referenced here only by user_id. Phosra’s product tables do not store the parent’s raw email.

Child — a kid's profile

This is the most sensitive object. It is deliberately thin.

Field	Classification	Why it’s collected
`id`	Identifier	Primary key.
`family_id`	Identifier	Foreign key → `Family`.
`name`	PII (child)	First name / display name only. No surname is required.
`birth_date`	PII (child)	Drives the age band and rule defaults. This is the reason Phosra exists — an age-appropriate policy is impossible without it.
`avatar_url`	Optional	Parent-supplied image URL; nullable and usually `null`.
`created_at` / `updated_at`	Metadata	Lifecycle timestamps.

Never collected on a child: device identifiers tied to advertising, precise geolocation, biometrics, contacts, browsing history, or message content. Enforcement happens against categories, not against a log of what the child did.

ChildPolicy + PolicyRule — the ruleset

Policy state is configuration, not behavior. A PolicyRule records which of the 123 OCSS categories is on and its config — never an event that a rule fired against a specific child action.

Object	Sensitive fields	Notes
`ChildPolicy`	none	`name`, `status`, `priority`, `version`.
`PolicyRule`	none	`category`, `enabled`, `config`. Category config is policy intent (e.g. `max_ratings`), not child data.

Enforcement + audit — the durable record

Object	What it holds	Retention driver
`EnforcementJob` / `EnforcementResult`	Which policy was pushed to which platform, and the per-platform outcome. Provider response payloads are captured in `details` for debugging.	Operational + regulatory defensibility.
Audit log	Every enforcement decision — rule, input, output, statute citation — on a durable event stream.	Compliance reporting; see retention below.

The data-plane EnforcementReceipt is identity-free by construction — no child ref, device id, or user id (see Data model → EnforcementReceipt). The router that moves OCSS signals cannot decrypt the payload it carries; the envelope is sealed to the recipient’s key. See Content monitoring.

What Phosra never does with child data

No sale or brokering

Minor data is never sold, rented, or brokered — ever.

No ad targeting

Child data is never used for advertising or ad targeting, and never shared with ad networks or data brokers.

No external model training

Child data is never used to train external ML models.

No content logging

Phosra enforces against categories. It does not keep a log of a child’s messages, browsing, or activity.

Retention

Data class	Default retention	Configurable?
Child profile + policy state	Life of the account; erased on parent-initiated deletion (below).	Yes — parent-initiated erasure at any time.
Enforcement + audit logs	Retained only as long as required for regulatory defensibility.	policy preview
Backups	Purged on the standard backup-rotation cycle after a live-store delete.	policy preview

Retention windows are parent-configurable, and defaults follow the most conservative applicable statute (COPPA / UK AADC). The exact numeric windows and the backup-rotation period are governed by the DPA rather than the API — request them from security@phosra.com for a security review. They are tagged policy preview here because they are not readable from the sandbox or OpenAPI spec.

Right to erasure — a real, runnable flow

Erasure is not a support ticket. Deleting a Family cascades to every Child, ChildPolicy, PolicyRule, and enforcement record beneath it, and deleting a single Child erases just that child’s subtree. Both are ordinary DELETE calls that return 204 No Content.

Every request and response below was captured live against the public sandbox https://phosra-api-sandbox-production.up.railway.app on 2026-07-06 — so you can run this end-to-end right now. In production these routes require your phosra_live_… key and an owner/parent role on the family. See Authentication and Environments.

Erase a single child

DELETE /children/{childID} removes the child profile and its entire policy subtree.

# childID from when you created the child (or POST /setup/quick)
curl -i -X DELETE "$PHOSRA_BASE_URL/children/e6e094ee-de89-4dc2-98b2-cd3c3a28309e"
# → HTTP/2 204

Verify it’s gone — a read of the erased child returns 404, not a soft-deleted tombstone:

curl -s "$PHOSRA_BASE_URL/children/e6e094ee-de89-4dc2-98b2-cd3c3a28309e"
# → 404  {"error":"Not Found","message":"child not found","code":404}

Erase the whole household (cascade)

DELETE /families/{familyID} erases the family and everything beneath it in one call — proven live: a child created under the family reads 404 immediately after the family delete.

curl -i -X DELETE "$PHOSRA_BASE_URL/families/ec5bc0d7-e02c-42f8-b821-c71d926f27d2"
# → HTTP/2 204

# The child that lived under it is now gone too:
curl -s -o /dev/null -w "%{http_code}\n" \
  "$PHOSRA_BASE_URL/children/d48d0260-1881-449e-98f8-7aa21dae546c"
# → 404

Removing one guardian, not the household: to detach a single parent/guardian without erasing anyone’s data, use DELETE /families/{familyID}/members/{memberID} (also 204). That removes the person’s access; it does not delete the children.

Data portability / export

Machine-readable JSON exports for portability (GDPR Art. 20 / CCPA) are available on request — email security@phosra.com. There is no self-serve export endpoint on the API today (a GET …/export returns 404) — we say so plainly rather than imply one exists. A self-serve export API is policy preview.

Encryption

In transit — TLS 1.3 + HSTS

HTTPS is enforced end-to-end with TLS 1.3; HSTS at the edge. A conservative Content-Security-Policy restricts script, frame, form, base, object, and worker sources. Plain-HTTP requests are redirected, never served.

At rest — AES-256-GCM

Postgres with tenant scoping enforced at the application layer on every query. AES-256-GCM is applied to sensitive fields (OAuth tokens, provider credentials) on top of standard at-rest disk encryption.

Sealed data-plane envelope

OCSS signals are sealed end-to-end to the recipient’s key. The routing layer reads only the headers it needs to move a signal — the router structurally cannot decrypt the payload. See Content monitoring.

Short-lived auth

Production auth runs on WorkOS with short-lived JWTs and a separate sandbox tenant for development. Admin actions are gated behind explicit role checks on every request.

Data residency & subprocessors

US-primary data residency across all subprocessors. Phosra updates this list when the data path changes; the Trust Center is the authoritative copy.

Subprocessor	Purpose	Region
Supabase	Postgres database + object storage	US
Railway	API compute (`phosra-api`)	US
Vercel	Edge CDN + Next.js hosting	Global edge, US origin
WorkOS	Authentication (JWT / AuthKit)	US
Sentry	Error tracking + performance monitoring	US
Resend	Transactional email	US

Need the signed subprocessor DPA for your vendor review? Request it at security@phosra.com.

Regulatory alignment

Phosra maps its controls to the statutes that govern children’s data. Conformance is evidence a regulator can weigh — not an approval Phosra issues, and not a safe harbor.

Framework	How Phosra aligns
COPPA / COPPA 2.0	Verifiable parental consent, minimum-necessary collection, and parent-initiated deletion are built into the enforcement engine.
GDPR-K / GDPR (Art. 8 child consent, Art. 17 erasure, Art. 33 breach notice)	Erasure is a live `DELETE` (above); breach notification within 72 hours; data-minimized child object.
UK AADC (Age-Appropriate Design Code)	High-privacy defaults, no profiling, no nudges — enforceable policies in the registry, not documentation wishes.
KOSA	Duty-of-care surfaces mapped across the OCSS rule categories.
EU DSA (Art. 28)	Minor-protection obligations supported via queryable audit trails and transparency-report-ready exports.
CCPA / CPRA	No sale/share of minor data; deletion and portability honored.

See the compliance hub for the per-statute detail pages.

Report a vulnerability

Phosra welcomes good-faith security research.

Email security@phosra.com

Send findings to security@phosra.com. We triage within one business day and keep you updated through remediation.

Stay in scope

Don’t access data that isn’t your own, don’t test against production parent or child accounts, and don’t run scanners that degrade service. Use the open sandbox for testing — it holds only synthetic data.

Coordinated disclosure

Give us a reasonable window to remediate before public disclosure. With your permission, we credit researchers in our disclosure log.

Incident response. On a confirmed incident Phosra follows a documented playbook — contain, assess, notify, remediate — with breach notification within 72 hours of confirmation, consistent with GDPR Article 33 and CCPA. Affected parents are contacted directly via the email of record.

Where to go next

Trust Center →

The authoritative, verifiable security & governance posture.

Core objects & data model →

Every field of every object this page classifies.

Environments →

Sandbox vs. production, and why the sandbox holds only synthetic data.

Authentication →

Keys, roles, and the owner/parent gate on destructive calls.

​Data minimization — collect the least that works

​What each object stores

​What Phosra never does with child data

No sale or brokering

No ad targeting

No external model training

No content logging

​Retention

​Right to erasure — a real, runnable flow

​Erase a single child

​Erase the whole household (cascade)

​Data portability / export

​Encryption

In transit — TLS 1.3 + HSTS

At rest — AES-256-GCM

Sealed data-plane envelope

Short-lived auth

​Data residency & subprocessors

​Regulatory alignment

​Report a vulnerability

​Where to go next

Trust Center →

Core objects & data model →

Environments →

Authentication →

Data minimization — collect the least that works

What each object stores

What Phosra never does with child data

Retention

Right to erasure — a real, runnable flow

Erase a single child

Erase the whole household (cascade)

Data portability / export

Encryption

Data residency & subprocessors

Regulatory alignment

Report a vulnerability

Where to go next