Security Details

1. Our approach

Easy Books applies layered administrative and technical safeguards intended to preserve the confidentiality, integrity, and availability of account and bookkeeping information. We design controls around least-privilege access, tenant separation, secure defaults, authenticated changes, and traceable activity.

Security is an ongoing process. We maintain and improve safeguards to the best of our ability within reasonable technical, operational, and financial limitations. No website, storage system, network, encryption method, or organization can guarantee absolute security or eliminate every risk.

2. Connections and browser protections

• Production deployments are intended to terminate traffic over HTTPS with modern TLS, and the application issues HTTP Strict Transport Security when a request is already HTTPS.
• A Content Security Policy restricts many script, frame, style, font, connection, and image sources. Some required third-party services, such as Stripe and Cloudflare, and limited inline styles are permitted where needed for the service to function.
• Framing is denied to reduce clickjacking risk, and content-type sniffing is disabled.
• Referrer and browser permissions policies limit unnecessary information and access to features such as camera, microphone, and geolocation.

3. Passwords, account identifiers, and application secrets

• Passwords are never stored in plaintext. They are processed with an adaptive password-hashing algorithm and automatically rehashed when stronger settings are needed.
• Password policy requires a minimum length and a mixture of uppercase, lowercase, and numeric characters.
• Usernames and email addresses are encrypted at rest with authenticated encryption. Separate keyed lookup values allow sign-in and duplicate checks without searching plaintext fields.
• Authenticator secrets and payment-provider secrets are encrypted before database storage.
• Two-factor recovery codes are stored as one-way hashes. Plaintext recovery codes are shown once at enrollment and may briefly exist in the authenticated session for that one-time display.
• Encryption keys, database credentials, and email-provider credentials are kept in server configuration rather than committed to application source code. Stripe API and webhook secrets are encrypted in application storage and may also use environment fallbacks during setup.
• Password-reset tokens are stored as hashes, expire after a short period, and are protected by flood controls and response delays.

4. Authentication and session security

• Authenticated sessions require both a secure browser session and a signed authentication token backed by an active server-side session record.
• Session identifiers and CSRF tokens are generated with cryptographically secure random values and session identifiers are regenerated at sign-in.
• PHP sessions are configured for cookie-only use and strict session mode.
• Authentication cookies are configured as HttpOnly and SameSite=Strict and are marked Secure over HTTPS.
• Signed authentication tokens include server-side token identifiers that can be revoked independently of the browser cookie.
• Sessions have inactivity and absolute lifetime limits, and concurrent sessions are capped by account role.
• Sessions are associated with the originating IP address and a cryptographic hash of the browser user agent to help detect reuse from an unexpected context.
• Users can review active sessions and revoke them. Password changes, forced password-change flows, account deactivation or deletion, and certain administrative security actions revoke existing sessions. Changing a profile email address alone does not automatically revoke active sessions.

5. Two-factor authentication and login protection

• Users can enable time-based authenticator-app two-factor authentication.
• MFA enrollment must be confirmed with a current code before activation.
• Login challenges expire, limit verification attempts, and prevent reuse of an already accepted authenticator time step.
• Single-use recovery codes are issued at enrollment and validated against stored hashes.
• Login attempts are subject to account- and network-based flood controls, failure recording, lockouts, and response delays.
• Accounts may be required to change an assigned temporary password before using the rest of the application.
• Authentication errors are intentionally generic to reduce disclosure of whether a particular account exists.
• Public access and contact forms use honeypot fields, signed form-start tokens, timing checks, validation, and Cloudflare Turnstile to reduce automated abuse.

6. Authorization and account separation

• Application queries and file operations are scoped to the authenticated company account.
• Server-side role checks restrict company users, accountants, and platform administrators to authorized pages and actions.
• Platform administrators are restricted from company bookkeeping screens, while retaining the limited account and profile access needed to administer the service.
• Accountants can enter a company workspace only after an authorized assignment or invitation. Acting-as activity is associated with both the accountant and company.
• Subscription and plan-feature restrictions are enforced by the server as well as hidden in the interface, so direct URL or API requests do not bypass entitlements.
• Accounts in cancellation retention are placed into read-only mode until their scheduled deletion.

7. Application and database safeguards

• State-changing forms and authenticated API requests use CSRF tokens validated on the server.
• Database access uses prepared statements and authenticated account identifiers rather than trusting user-supplied ownership values.
• Inputs are validated and normalized for their intended use, and displayed values are encoded to reduce injection and cross-site scripting risks.
• Sensitive actions require the appropriate HTTP method, authentication, role, entitlement, and ownership checks.
• Duplicate imports, repeated webhook deliveries, and concurrent storage changes use database constraints, transactions, or locking where appropriate.
• Detailed internal errors are logged on the server while users receive limited public error messages that avoid exposing credentials or implementation details.

8. Statements and transaction attachments

• Uploads are restricted by allowed file type, detected MIME type, extension, file-size limits, and magic-byte checks that inspect the beginning of the file contents.
• Uploaded files receive generated stored names and account-scoped storage paths rather than being served directly under their original names.
• Downloads require an authenticated, authorized request and an ownership match. Attachment links also use opaque access tokens.
• Storage quotas are checked under a per-account lock to reduce concurrent uploads exceeding the purchased allowance.
• Locally stored files are placed in a protected application directory with restrictive permissions.
• When S3-compatible object storage such as Backblaze B2 is configured, uploaded objects request AES-256 server-side encryption and use application-controlled object keys rather than direct public file paths.
• File hashes may be recorded as object metadata to support integrity verification and storage migration checks.
• Deleting a statement or attachment removes the stored object as well as its application record; account deletion also attempts to purge all account-owned stored files.

9. Billing and payment safeguards

• Full payment card details are collected by Stripe-hosted payment components and do not pass through or remain on Easy Books servers.
• Easy Books stores only the billing identifiers, status, and limited card metadata returned by Stripe that are needed to administer subscriptions.
• Stripe API credentials and webhook secrets are encrypted in application storage.
• Incoming billing webhooks are signature-verified and event identifiers are claimed atomically to reduce tampering and duplicate processing.
• Billing API requests require an authenticated company account, CSRF validation, and server-side validation of plans, prices, storage, and subscription state.

10. Logging, monitoring, and accountability

• Security logs record relevant events such as sign-in failures, lockouts, session changes, MFA changes, password changes, and administrative actions.
• Company activity logs identify the company, acting user, session, event type, time, and relevant details for supported actions.
• IP addresses and browser identifiers may be recorded for session security, abuse prevention, and incident investigation.
• Accountant acting-as actions and important billing, access, import, export, and deletion events are recorded where supported.
• Logs are access-controlled and are used for security, support, accountability, and service operation rather than advertising.

11. Service providers and storage locations

Easy Books relies on carefully selected providers for parts of service delivery. Stripe processes subscriptions and payments; SendGrid delivers service email; Cloudflare supports network delivery and anti-abuse controls; and hosting or object-storage providers may store application data and uploaded files. Provider access is limited to what is needed for their function and is also governed by their own security programs, contracts, and policies.

12. Retention, deletion, and recovery limitations

• Disabling a feature or downgrading a plan preserves existing feature data but blocks access until the feature is restored.
• Company account holders can request immediate deletion or select a 90-day read-only retention period before deletion.
• The deletion process removes application records and account-owned statement and attachment objects, subject to errors that may require support intervention.
• Limited security, billing, email-delivery, provider, or backup records may remain where legally or operationally required and are not all controlled directly by Easy Books.
• Backups and provider systems may retain deleted information until their normal overwrite or retention cycle completes.

13. Shared responsibility

Users and organizations also play an important role in protecting their information:

• Use a unique password that is not shared with another service.
• Enable authenticator-based two-factor authentication and store recovery codes securely.
• Keep devices, browsers, email accounts, and authenticator apps protected and up to date.
• Review active sessions and account activity and revoke anything you do not recognize.
• Grant accountant access only to trusted people and remove access when it is no longer needed.
• Do not upload information you are not authorized to store or process.
• Keep independent copies of records required for tax, legal, or business-continuity purposes.

14. Reporting concerns and updates

If you believe an Easy Books account or data may have been compromised, change the account password, revoke unfamiliar sessions, enable two-factor authentication, and contact your account administrator or Crown Internet LLC promptly. Do not include passwords, MFA secrets, recovery codes, full payment card numbers, or other unnecessary sensitive information in a report.

Safeguards may change as threats, technology, providers, and the application evolve. This page describes current controls at a practical level and does not create a warranty, certification, service-level commitment, or guarantee against unauthorized access, data loss, service interruption, or other security incidents.