Security
Last updated 21 August 2026
Foorsite holds contracts, drawings, programmes, commercial figures and records about the people on your sites. This page sets out how that is protected, item by item, against a forty-point framework covering security, privacy and operational practice.
It includes what is still in progress. A page that claimed everything was finished would be easy to write and worth nothing — the rows marked in progress are why the rest can be taken seriously.
40 items reviewed. In place means working and verified today. In progress means real work is underway and the remaining step is known. Gated means the feature it belongs to has not shipped yet, and the control is a condition of shipping it.
Security
| Secrets management | In place | No credentials in our codebase or its history; checked automatically, and every key has a documented rotation procedure. |
| Keys in the browser | In progress | No credential that grants access to customer data is exposed to the browser. One low-value third-party key for a weather widget is being moved server-side. |
| Database-level isolation | In progress | Separation between customer accounts is enforced in the application on every request. A second, database-level layer of the same rule is being rolled out beneath it. |
| Server-side authorisation | In place | Every request is authorised on the server against your membership. Nothing trusts a role or an identifier sent by the browser. |
| Rate limiting | In progress | Anonymous entry points, AI features and anything that sends email are throttled. Sign-in throttling is provided by our authentication platform; moving it in-house is planned. |
| Database query safety | In place | All database access uses parameterised queries. Free-text search terms are escaped before they reach the database. |
| Input validation | In progress | Anonymous submissions and anything that costs money or sends mail are validated and size-capped. Schema validation is being extended across the remaining endpoints. |
| Cross-site scripting | In place | All rendered content is escaped or sanitised before display, including AI output and uploaded graphics. Covered by tests that assert specific attack payloads are neutralised. |
| Password storage | In place | Passwords are held by our authentication provider and never by us. We have written no password cryptography of our own. |
| Session handling | In place | Sessions use secure cookies. No authentication token is ever stored where browser scripts could read it. |
| Administrative access | In progress | Administrative rights are checked on the server from your company membership. A review is tightening the few screens that decide this less strictly. |
| Cross-origin policy | In place | The API accepts requests from our own application only. No wildcard or reflected origins. |
| Email verification | In progress | Sign-up requires confirming an email address before an account is usable. The provider-side setting is being captured in our configuration records. |
| Record identifiers | In place | Identifiers are random and cannot be guessed or enumerated, and access is checked on fetch rather than relying on that. |
| Field-level write protection | In progress | Ownership fields are set on the server and cannot be supplied by a request. Whitelisting is being extended to the remaining commercial forms. |
| Inbound webhooks | In place | The one inbound webhook verifies its cryptographic signature before anything is processed, and refuses to run if its secret is unset. |
| Error handling | In progress | Sign-in failures return a single constant message, so accounts cannot be enumerated. Scrubbing internal detail from other error responses is in progress. |
| Dependency vulnerabilities | In progress | Dependencies are audited automatically on every build, which fails on a new high-severity finding. One library with no published fix is tracked with a documented plan. |
| Password policy | In progress | Minimum-length rules apply at sign-up and reset. Consolidating them into one shared rule across every path is in progress. |
| File uploads | In progress | Uploads require an account, are scoped to your company, and filenames are sanitised. Server-side size and type limits are being applied consistently across all upload paths. |
Privacy & legal
| Privacy policy | In place | Published and linked from sign-up and sign-in, written from what the software actually does rather than a template. |
| Disclosure of what we collect | In place | The privacy policy sets out what is collected, why, and how long it is kept — including site attendance and induction records. |
| AI disclosure | In place | We name our AI providers, state plainly that uploads and questions are sent to them, and that AI output can be wrong and is advisory only. |
| Sub-processors | In place | A published register of every third party that receives customer data, and exactly what each one receives. It is generated from the same source the software uses. |
| Account deletion | In place | Self-service. Personal data is destroyed; project records remain so the job keeps a coherent history, with your identity removed from them. You are shown exactly what was deleted and what was kept. |
| File storage privacy | In progress | Documents are served through short-lived links checked against your company. Consolidating the last legacy storage locations onto that path is in progress. |
| Marketing claims | In place | We display no testimonials or customer logos we have not been given permission to use. |
| Cancellation | In place | Cancelling is as easy as signing up: self-service, no phone call, no retention interview. Published in our terms as a commitment. |
| Renewal reminders | Gated | We commit in our terms to emailing before any renewal or price change. The reminder ships with the billing feature it belongs to. |
| AI safety | In place | Every AI feature carries a safety instruction applied centrally, so someone in distress is pointed to real support rather than a business answer. Enforced by a test across all model calls. |
| Terms of service | In place | Published, covering acceptable use, your ownership of your content, AI limitations and liability. Your content is never used to train AI models. |
Practice
| Prompt injection | In progress | Document text and forwarded email are fenced as evidence rather than instructions before reaching a model, and actions that change your data need a person to confirm. |
| Isolation testing | In place | An automated census classifies every endpoint and fails our build if one is added without an access check or a written justification. |
| AI provider terms | In progress | A register of each provider’s training and retention position, with an honest column for what we have verified directly and what we have not. |
| Backups and recovery | In progress | Managed backups are in place through our database platform. A documented restore drill is scheduled — we do not describe a backup as proven until it has been restored. |
| Audit logging | In progress | Administrative actions and data exports are recorded to a log designed so its own subjects cannot alter it. Broadening coverage is in progress. |
| Access and offboarding | In progress | A written offboarding runbook and an access inventory covering every system. Multi-factor authentication is a recorded decision under review. |
| Security headers | In progress | Transport security, clickjacking and content-type protections are enforced. A content security policy is running in reporting mode ahead of enforcement. |
| Data subject requests | In place | Any user can export everything we hold about them, at any time, without asking us. The export deliberately excludes colleagues’ personal data. |
| Disclosure and key management | In place | A published security contact with stated response times, plus written rotation, offboarding and incident procedures. |
How this is kept honest
The counts above are calculated from the table, not written by hand, so the summary cannot drift from the detail. Behind this page we keep a fuller internal record with the specific evidence for each row — which file enforces what, and which test would fail if it stopped being true.
Several protections are enforced by our build: it fails if a new endpoint is added without an access check, if a known category of vulnerability reappears, or if a new high-severity dependency issue is introduced. These are not periodic reviews, they run on every change.
Talk to us
If you are assessing Foorsite on behalf of a client, we are glad to walk through any row here in detail, including the evidence behind it and the plan for anything in progress. Write to [security contact address].
If you believe you have found a security problem, please tell us — our disclosure policy, including response times and what we ask of researchers, is published in SECURITY.md in our source repository.