Security Overview

01 Our position

Inspection records are evidence. They are relied on in transactions, insurance claims, regulatory filings and litigation. A record that can be tampered with, lost, or attributed to the wrong person is worthless. Security here is a product requirement, not a compliance checkbox.

02 Application security

• All database access goes through a parameterised query layer. User input is never concatenated into SQL, which structurally eliminates SQL injection rather than filtering for it.
• Every template output is contextually escaped by default, preventing cross-site scripting.
• Mass assignment is explicitly guarded on every model, so a crafted request cannot set a field the form never exposed.
• All state-changing requests require a per-session CSRF token.
• File uploads are validated by MIME type and size, stored outside the executable path, and served with a nosniff header.
• Server-side validation is enforced on every input, independent of any client-side validation.

03 Transport and browser controls

Every response carries a defensive header set:

• Content-Security-Policy restricting scripts, styles, images, fonts and connections to this origin, with a per-request nonce for inline bootstrap code.
• form-action restricted to this origin, so an injected form cannot post credentials to an attacker.
• frame-ancestors set to none, blocking clickjacking and overlay phishing.
• Strict-Transport-Security with preload, over TLS.
• X-Content-Type-Options, Referrer-Policy, Permissions-Policy and Cross-Origin isolation headers.

All stock imagery is served from our own origin rather than an external CDN, so no visitor data leaves this site and the policy can stay strict.

04 Authentication and access

• Passwords are hashed with bcrypt and never stored or logged in recoverable form.
• Login endpoints are rate limited per account and per IP address, with progressive lockout.
• Session identifiers are regenerated on authentication and invalidated on logout.
• Session cookies are encrypted, HTTP-only and SameSite restricted.
• Staff and client portal users authenticate against separate guards with separate session scopes.
• Access is governed by a department and role permission matrix — a role only reaches the functions it was explicitly granted.
• API access for mobile and offline clients uses scoped bearer tokens that can be revoked per device.

05 Data integrity and audit

Every inspection record carries a UUID, a version counter and a device timestamp. Offline synchronisation is conflict-aware: concurrent edits are resolved by rule, recorded as a conflict with both sets of values preserved, and surfaced to the project lead. Nothing is silently overwritten.

Assignments, status transitions, approvals, report releases and report downloads are all written to an append-only audit log attributable to a named user, with IP address and user agent.

06 Reporting a vulnerability

If you believe you have found a security issue, email support@inspectionviewer.com with the subject line "Security". Include enough detail to reproduce the issue.

We ask that you give us a reasonable opportunity to remediate before public disclosure, that you do not access, modify or destroy data belonging to others, and that you do not degrade the service for other users. We will not pursue action against researchers who act in good faith within those bounds.