Your staff records, and what stands between them and everybody else

The usual way to keep one customer's data away from another is to filter it in the application. That works until a single query is written without the filter. CrewSharp does it one layer down: every table carries a policy in Postgres that decides, per row, whether the signed-in identity may read or write it. The check runs inside the database, on every request, whether it came from the app or from anywhere else.

The identity comes from the session, never from anything the browser sends along with the request. A modified client cannot ask for another organization's rows, because the question is not being answered by the client.

The permission checks you see in the app are the second line

Roles and permissions inside CrewSharp control what a person is offered: whether they see the reports tab, whether the edit button is there. Those are conveniences. If a role is misconfigured, the database still refuses. We treat the interface as a way to keep people out of places they have no business in, and the database as the thing that actually holds the line.

Policies are code, and code regresses. A migration that quietly widens who can read a table type-checks fine and passes every unit test, because a unit test cannot see a database policy. So the release gate runs a set of live authorization probes against a real database: it signs in as one organization and tries to read another's, one store and tries to reach another store, a trainer and tries to do an owner's job. If any probe gets data it should not, the gate fails.

• Live cross-organization and cross-store read probes, run against a real database rather than a mock
• A pre-push hook that blocks a push to the main branch on type errors and four security guards
• Continuous integration on every push: types, edge function types, and the full test suite
• A gate that refuses to report a pass for anything it did not actually run

Nothing secret reaches the browser

The only credentials in the shipped bundle are the public project URL and the public anonymous key, which are designed to be public and are useless without a valid session. The server-side key that can read across organizations lives in server configuration and is never committed, never bundled, and never sent to a client.

Headers that limit the damage a bad script could do

The site sets a Content Security Policy, HSTS, frame denial, referrer and permissions policies. The connection policy is pinned to our one backend rather than allowing the whole provider, so even a successful script injection has nowhere to send data to.

Spreadsheet imports are contained

Roster and schedule files are parsed off the main thread, in a worker created for that one file and destroyed straight after, behind a size cap, a file-type allow-list and a hard timeout. A hostile spreadsheet fails one import in one person's browser rather than reaching anything else.

Changes leave a trail

Security-relevant table changes are recorded by a database trigger that clients cannot write to, so the record of who changed what is not something the app can be talked into editing.

• Export everything CrewSharp holds for your organization as a file, from inside the app, at any time
• Delete your account and its records when you are done
• Payments run through Stripe's hosted checkout, so card details never reach us
• Two-factor sign-in is available per account
• Rate limits on every path that can send email, so no address can be used to flood somebody

In data-protection terms you are the controller of your employees' records and CrewSharp is the processor. Our Terms and Privacy Policy say so, are readable without an account, and describe what each side is responsible for.

A trust page that only lists strengths is not evidence of anything. So, plainly: CrewSharp has not been through a SOC 2 or ISO 27001 audit and holds no security certification. There is no bug bounty and no third-party penetration test. Two-factor sign-in holds the application at a challenge screen, but the database policies do not currently require it, so it protects the app rather than the raw API.

These are the honest limits of a small independent product, and they are written down in the repository as well as here. If any of them is a blocker for your group, say so early and we will tell you straight whether it is on the roadmap.