Security
- Last updated:
- 1 October 2026
- Policy version:
- 2026-10-01
- Effective:
- 1 October 2026
1. Overview
This page describes security controls built into BolHisab. It is not a certification: BolHisab does not currently hold SOC 2, ISO 27001 or similar certifications.
2. Accounts and sign-in
- Passwords are stored only as salted scrypt hashes; sign-in requires a verified email address.
- Optional two-factor authentication (authenticator app codes) for users; administrators have their own sign-in with two-factor support.
- Emailed links (verification, reset, invitations) are single-use, stored only as hashes and expire.
- Repeated failed sign-ins and sensitive actions are rate limited.
- Session tokens are random, stored only as hashes, sent in HttpOnly cookies (Secure and host-only in production), and revoked on password reset.
3. Access control and isolation
- Every request is checked against your membership of the business, and the business comes from your server-side session, not from the request.
- Role-based permissions (Owner, Admin, Accountant, Staff, CA, Viewer); CA access to a business needs the owner's approval and can be time-limited or revoked.
- Database constraints prevent records from one business referring to another's accounts.
- BolHisab support staff can enter a business only through a logged, time-limited support session.
4. Record integrity and audit
- Posted journal entries cannot be edited or deleted; corrections are reversing entries. The database rejects unbalanced journals.
- Audit logs record who did what and when, with IP address and browser, and are append-only. Administrative actions have a separate append-only log.
5. Data protection
- Connections use HTTPS; production deployments must use an https address and send HSTS.
- Security headers include a Content-Security-Policy, X-Frame-Options DENY and nosniff.
- Uploaded files are checked by their content (not their name or declared type), size-limited, stored privately and served only through authenticated requests. CA vault files are encrypted at rest with AES-256-GCM. API keys saved by administrators are stored encrypted.
- Browser requests that change data must come from our own origin (CSRF protection).
6. Hosting and backups
The Service runs on infrastructure provided by our hosting provider (see Subprocessors). Database backups and physical security are provided by that infrastructure according to its configuration.
7. Reporting a vulnerability
Please report suspected vulnerabilities to [SECURITY CONTACT EMAIL] with steps to reproduce. Do not access data that is not yours, disrupt the Service or publicly disclose the issue before we have had a reasonable opportunity to fix it. We will acknowledge good-faith reports.