Security Overview

Our approach

Security is the first requirement on every piece of WorkOSync, not a feature added later. Protection against spam, bots, brute force and abuse is built in from the first commit of every service and verified with real requests after every deploy. The controls below are the standing definition of “protected” that every part of the platform must meet before it goes live. Sixty Seven Digital FZCO is based in Dubai and hosts customer data in secure European data centres, encrypted and backed up daily.

Transport security: HTTPS and HSTS everywhere

Every page, API endpoint, document link, webhook and admin surface is served only over TLS 1.2 or higher with modern cipher suites. Plain HTTP does nothing except answer certificate challenges and redirect permanently (301) to HTTPS. HTTP Strict Transport Security is enabled with a long max-age and includeSubDomains, so a browser that has visited once will never attempt a plaintext connection again. Certificates are issued and renewed automatically and monitored for expiry.

Security headers

Brute-force, bot and abuse protection

• Login. Escalating per-IP lockout (a short block, then 24 hours, then permanent), per-account throttling that slows attempts without letting an attacker lock the real owner out, and constant-time credential checks that compare against a dummy hash for unknown users so response timing cannot reveal whether an account exists. Identical failure responses in every case.
• Every public form. A hidden honeypot field that bans the address on any fill, a signed render-time token with a minimum-fill-time trap that rejects submissions faster than a person could type, Cloudflare Turnstile, per-IP and per-endpoint rate limits, small request-body limits and link-spam heuristics.
• Site-wide bot classifier. Penetration tools, scanners, scrapers and raw HTTP libraries are refused with a 403 on every route and banned at the firewall on repeat. Search engines and link-preview crawlers are allowed so the public site indexes and share cards work. No bot of any kind reaches the admin or app surfaces, which return 404 to them.
• Probe banning. Requests for known scanner targets (.env, .git, wp-login.php, xmlrpc.php, phpunit and similar) are logged and the source is banned immediately at the application and at the firewall.
• Blocked means blocked. A banned address is refused on every request, not just the endpoint it abused, and behind our proxy the client address is taken from the hop the proxy appended, never from an attacker-controlled header.

Authentication, sessions and access control

• Passwords are stored only as bcrypt hashes with a per-password salt and are never logged or emailed. Minimum length and breached-password checks apply at signup and change.
• Sessions are server-side records referenced by a random token in an httpOnly, Secure, SameSite cookie, validated on every request and revocable by the user and by admins. Two-factor authentication is available to everyone and required for owners and admins.
• Role-based access control with eight built-in roles and per-module permissions; every query is scoped to the company, and portal users reach only their own records.
• Every sign-in, permission change and create, update or delete is written to an audit log the owner can review and export.
• Admin surfaces are protected by same-origin checks and a server-action allow-list, so a forged or replayed request cannot invoke a privileged action.
• Production access for our own staff is limited to named engineers with hardware-backed multi-factor authentication, and all access is logged.

Encryption of data and secrets

Data is encrypted in transit with TLS and at rest in the database, file storage and backups. Secrets that a customer entrusts to us, such as payment gateway credentials, AI provider keys, SMTP passwords and webhook signing keys, are encrypted with a server-held key before they are stored, are never returned to the browser after entry, and are decrypted only at the moment a request must be signed. Secrets are generated on the server and never passed through chat, email or tickets. Keys are rotated on a schedule and immediately if a compromise is suspected.

Data hosting and isolation

WorkOSync is hosted in secure European data centres. Each company's database, uploaded files and backups are encrypted in transit and at rest. Companies are logically isolated: every record carries its company identifier and every query is filtered by it at the data-access layer, so a bug in one screen cannot expose another customer’s data. Uploaded images are re-encoded on upload and uploaded documents are served with a sandboxing policy so that a malicious file can never execute in another user’s browser.

Backups and resilience

The database and uploaded files are backed up every day, encrypted, and kept for a rolling 35 days in the company’s region. Restores are tested on a schedule, and a restore always migrates the schema forward so that an older backup can be recovered onto the current release safely. Owners can also take an on-demand full backup from the admin console and download it. Production processes run under a supervisor with a liveness probe that restarts a process that is running but no longer answering, so a hang is corrected in seconds without waiting for a human. Capacity is provisioned with headroom for the busiest days of the month.

Monitoring, vulnerability management and incident response

• External uptime monitoring from several locations and application-level error alerting, with a public status page during incidents.
• Before every deploy we run a dependency audit and check the framework’s own advisory feed, because frameworks vendor copies of libraries that a top-level version check can miss. Nothing with a known critical or high vulnerability in the request path goes live.
• Every change is reviewed for security impact before release, and the abuse controls are exercised with real requests after deploy: a bad-bot user agent and a probe must be refused and banned, a browser and a search crawler must succeed, and a bot must get 404 from the admin.
• A documented incident response process covers detection, containment, eradication, recovery and a written post-incident review. Customers affected by a personal data breach are notified within 72 hours of confirmation, as committed in the Data Processing Addendum.

Responsible disclosure

If you believe you have found a vulnerability in WorkOSync, please email security@workosync.com. Include the affected URL or component, steps to reproduce, the impact you believe it has and, if you like, a name for acknowledgement. We acknowledge reports within one working day, keep you informed as we investigate, and aim to fix confirmed critical issues within 7 days and others within 30 days.

We ask that you test only against your own company and accounts, do not access or modify data that is not yours, do not run high-volume automated scanning, denial of service, social engineering or physical attacks, and give us reasonable time to fix an issue before publishing anything. Research that follows these rules is authorised under our Acceptable Use Policy, and we will not take legal action over it. We publicly thank researchers who report valid issues, with their permission, and may offer a reward at our discretion for significant findings.

Compliance

WorkOSync is designed to help customers meet the UAE Personal Data Protection Law (Federal Decree-Law No. 45 of 2021) and, for EU and UK customers, the GDPR and UK GDPR, with a Data Processing Addendum that incorporates the Standard Contractual Clauses where they are needed. The accounting and tax modules follow UAE Federal Tax Authority requirements for tax invoices, VAT returns and record keeping. We will complete security questionnaires for customers on Scale and Enterprise plans and share the results of our internal reviews and any third-party assessments under a non-disclosure agreement.