Security and privacy

Security is part of the product, not a checkbox

PawPlacer handles animal welfare data like it matters: account-scoped, permissioned, validated, rate limited where public, and reviewed continuously as the product changes.

Built for private shelter operations

Pet records, applicant answers, medical notes, documents, donors, volunteers, payment settings, and team context are treated as sensitive operational data.

No selling or sharing user data

We do not sell or share user data, and we do not use it for ads, data brokerage, or third-party marketing.

Always auditing

We review security continuously in code, database functions, public endpoints, storage flows, API behavior, and permission boundaries.

Your organization's data stays separate

Workspace records, documents, payments, people, and pet data are tied to your organization. Another organization should not be able to reach your private workspace data by changing a link, filter, form, or request.

Access is checked close to the data

PawPlacer does not rely only on what buttons are visible in the browser. Sensitive reads and changes are checked on the server and in the database before private data is returned or modified.

Team permissions are deliberate

Owners can decide who should manage pets, people, reports, billing, API keys, team access, and administrative settings. Higher-risk actions have separate checks instead of one broad all-or-nothing permission.

Public forms are handled carefully

Applications, donations, volunteer forms, surrender forms, and uploads can be public, so they get extra validation before we accept information from someone outside your workspace.

Requests have abuse safeguards

We check that requests look like they came from the right place, match the expected shape, and are allowed for the current account before they change private records or files.

Privileged access is kept narrow

Some background jobs and trusted public workflows need elevated access. We keep those paths server-only and require them to verify the account, form, file, or workflow they are about to touch.

Public pages are treated as public entry points

PawPlacer has public listings, widgets, applications, donation flows, and adoption links. Those surfaces are designed differently from the authenticated workspace.

Public forms check that the requested form is enabled for the account before accepting submissions.

Public form submissions are rate limited by IP and account to reduce spam and automated abuse.

Public adoption and donation flows use tokenized or scoped server endpoints rather than exposing private workspace data.

Public pet listings are intentionally separated from private records and only expose public-facing pet information.

Data commitments

Animal welfare data includes people, payments, medical notes, applications, and private team context. We treat that as operational data, not an advertising asset.

We do not sell or share user data.

We do not use user data for advertising, data brokerage, or third-party marketing.

PawPlacer does not serve ads inside the product.

Payments run through the processors your organization chooses; PawPlacer does not handle card data directly.

Optional AI features are opt-in workflow tools, and the app keeps AI calls behind authenticated, CSRF-protected server routes.

Shared responsibility

Security also depends on how each organization configures PawPlacer: who has owner access, which public forms are enabled, where API keys are stored, which payment methods are connected, and whether optional AI features are turned on.

We make those controls visible in the app and are happy to review a real workflow before launch.

Technical details

The top of this page explains what customers should expect in plain language. This section is for teams that want the implementation version: how we review code, public entry points, database access, files, and privileged paths.

Technical controls we care about

Supabase SSR clients preserve authenticated sessions on the server without exposing service-role behavior to browser code.

Authenticated mutations use shared mutation patterns, query invalidation, and server-side authorization rather than component-local raw writes.

Public API keys are managed through database functions and rate-limit metadata, with read/write access levels and revocation support.

File paths are generated under account-scoped prefixes and deletion checks reject traversal, null bytes, malformed paths, and cross-account references.

Soft-deleted records stay filtered in the parts of the app that use soft deletes, including pets, driver profiles, and adoption follow-ups.

Logs and API responses are designed to avoid leaking secrets such as tokens, passwords, API keys, CSRF values, sessions, and auth codes.

How we audit

PawPlacer moves quickly, so security review has to be built into the way we build. We audit new work against the real risks in this product: tenant boundaries, public submissions, payment configuration, API access, files, documents, and role permissions.

Tenant-bound review

We audit frontend, server, and SQL changes for account_id scoping. Tenant data paths are expected to prove which account owns the read, write, file, form, API key, or payment configuration.

SQL safety review

Database functions are reviewed for access assertions, explicit volatility, safe search paths, deterministic list behavior, soft-delete filters, and careful use of SECURITY DEFINER.

Public-entry review

Any route that accepts unauthenticated traffic gets extra scrutiny: rate limits, schema validation, enabled-form checks, token checks, storage path validation, and error behavior.

Dependency and platform review

We keep security work active as part of normal engineering. That includes reviewing framework, Supabase, payment, email, storage, and AI integration changes when the app evolves.

Implementation notes

For teams that want the technical version, these are the patterns we audit against in the codebase. The short version: identify the account, verify access close to the data, keep public paths explicit, and make privileged bypasses narrow enough to reason about.

Tenant boundary

Workspace data paths carry account_id through loaders, hooks, mutations, RPCs, and storage paths.

Top-level account RPCs check account access before reading or writing tenant data.

Auth-optional public flows use explicit helpers instead of silently trusting an anonymous request.

Postgres hardening

Database functions are written with SET search_path TO '' so unqualified object resolution cannot drift.

Security-definer functions are reserved for intentional RLS bypasses and still perform domain-level checks.

Views use security_invoker='on' where they should respect the caller's row-level permissions.

Request validation

Route actions validate payloads with Zod schemas before reaching domain code.

UUID-like identifiers are checked before privileged public paths call database or storage operations.

Unexpected methods, missing CSRF tokens, malformed bodies, invalid paths, and unauthorized account access fail closed.

Public forms

Public submissions verify the account, table, template, and enabled-form state before accepting data.

Rate limits apply per IP and per account for public form submission pressure.

Public uploads must be tied to an enabled public form and pass file type, size, and path checks.

Storage

Uploads are written under account-scoped prefixes rather than caller-provided arbitrary paths.

Delete operations validate ownership with account-scoped path checks and reject traversal, null bytes, and malformed references.

Document and media helpers sanitize filenames and generated paths before storage writes.

API and automation

Public API routes use scoped API keys, access levels, revocation support, and endpoint-aware rate-limit metadata.

Sensitive automation routes use CSRF-protected server endpoints and database-backed rate limits where abuse would be expensive.

Server admin clients run with session persistence disabled and are kept out of browser code.

Questions about your setup?

Security depends on configuration too: role assignments, API key handling, public form settings, payment provider setup, and optional AI settings. If you want to review a real workflow before going live, contact us and we will walk through it with you.

Contact PawPlacer