Security for Irish pest control companies

Data is encrypted in transit (TLS/HTTPS) and at rest. Firebase and Google Cloud use industry-standard encryption for Firestore, Storage, and all services. Only authorised users can access customer and job data; roles control what each user can see and do.

• Encryption in transit and at rest
• Role-based access to customer and operational data
• Audit logging for key actions where applicable

Each company added to the platform receives its own Firebase project, including a dedicated Firestore database and Firebase Storage bucket. Your operational data, documents, and reporting remain logically and physically isolated from other tenants. This architecture supports compliance requirements, simplifies audit trails, and ensures that access control and security rules apply only to your organisation’s resources.

• Each company receives its own Firestore database and Storage bucket
• Complete data isolation between tenants; no shared data stores
• Supports compliance and simplifies audit trails

Sensitive PDFs can be protected with an owner password. In the Android app, Create Report offers an optional "Password protect PDF" checkbox; when enabled, you set an owner password and the PDF is encrypted. Viewing and printing are allowed; editing requires the password.

Action Form PDFs support the same optional password protection. When enabled, a dialog prompts for an owner password (required to edit the PDF). All generated PDFs (Action Forms and Create Report) use full compression and, when protection is enabled, encryption via iText.

• Create Report: optional owner password, view/print allowed, edit restricted
• Action Forms: optional password, technician/customer signatures, image attachments
• Encryption and compression for all generated PDFs

We do not store passwords. The Android app uses Firebase Authentication with email/password sign-in; the CRM uses Google OAuth via Firebase Auth. User identity and session are managed by Firebase; role is resolved from the Firestore staff collection (CRM) or user records (Android).

Offline login on the Android app is a local-only mode with no Firebase credentials; when logged in with Firebase, templates and API features are scoped to the authenticated user.

• Android: email/password sign-in via Firebase Auth
• CRM: Google OAuth via Firebase Auth
• Role from Firestore staff/user data; no password storage by the app

All access to Firestore is enforced by Security Rules. Rules implement role-based read/write, technician data scoping (e.g. techs only see their own contracts, jobs, and calendar), and calendar isolation. Lead editing and report deletion are restricted by role; token protection applies to shared accounts.

On the marketing site, preview/demo signup uses a create-only collection: no read, update, or delete from the client; schema and types are validated in rules. Other collections are only readable/writable when request.auth is set and token claims match the resource where applicable.

• Role-based read/write and technician scoping
• Calendar and contract isolation per technician
• Lead and report deletion restrictions; token protection for shared accounts
• Create-only and schema validation for public-facing signup

Reports and documents are stored in Firebase Storage with access controlled by Storage rules and application logic. Upload and rename permissions are role-based; super-admin-only deletion applies to protected reports. Folder-based organisation and metadata (where used) support secure browsing and audit.

• Secure document storage in Firebase Storage
• Role-based upload, rename, and delete
• Super-admin-only deletion for protected reports

Firebase App Check is used to reduce unauthorised API access: reCAPTCHA v3 on the web and Play Integrity or SafetyNet on Android. All sensitive or write operations from the marketing site go through callable Cloud Functions; there are no direct client writes to sensitive collections.

Every callable validates payload (schema, length, honeypot). Server-side validation ensures we never trust client input.

• App Check: reCAPTCHA v3 (web), Play Integrity/SafetyNet (Android)
• Callables for all sensitive writes; no direct client writes to sensitive data
• Server-side validation and schema checks on every callable

The Android app is distributed via Firebase App Distribution. Builds are delivered securely to your technicians and testers without publishing to the public Play Store. Access is controlled through the Firebase console: you manage who receives which release or pre-release build, track installs, and keep distribution within your organisation.

• Distributed via Firebase App Distribution
• Controlled delivery; no public store exposure
• Access and releases managed from Firebase

The CRM enforces super_admin, admin, and tech roles via Firebase Auth and Firestore rules. The Android app uses user IDs (e.g. 001, 002, 003, 004) for permission checks. Admins can assign work and manage all calendars and jobs; technicians see only their own schedule, contracts, jobs, and commission. Client-side route guards, Firestore rules, and Cloud Function validation all enforce the same model.

• CRM: super_admin, admin, tech with distinct capabilities
• Android: user-ID-based permissions; admins vs technicians
• Route guards, Firestore rules, and Cloud Function validation

Demo and signup endpoints are rate limited per IP and per email (e.g. per hour) to prevent abuse. Counters are stored in Firestore or in-memory with fallback; functions reject requests when limits are exceeded. Gmail API usage in the CRM is subject to server-side rate limiting.

• Per-IP and per-email rate limits on signup/demo
• Server-side rate limiting on email sending

Firebase Hosting is configured with security headers: X-Content-Type-Options, X-Frame-Options, Referrer-Policy, Permissions-Policy. Content Security Policy (CSP) is added where it does not break the site. These headers help prevent clickjacking, MIME sniffing, and other common web attacks.

• X-Content-Type-Options, X-Frame-Options, Referrer-Policy, Permissions-Policy
• CSP where applicable

No production secrets are committed to the repository. Environment variables and Firebase config are used for API keys and configuration. In the CRM, token storage for shared accounts (e.g. email) is restricted to super_admin. AI API keys (e.g. for the Android app) are stored in Firestore and only user 001 can update them via Settings.

• No production secrets in git; environment variables and Firebase config
• Token storage restricted to super_admin where applicable
• API keys in Firestore with admin-only write

The platform is suitable for commercial pest control, service maintenance, and regulated reporting environments. We follow security best practices and can support compliance reviews. Use strong passwords and do not share accounts; report any suspicious activity to your administrator.

• Encryption, access control, and audit practices
• Strong passwords and no account sharing
• Report suspicious activity to your administrator