Security at Cloudesk

1.Accounts and sign-in

• Passwords are hashed with Argon2id (19 MiB memory, 2 iterations) — the algorithm recommended by OWASP. We never store or see your password, and new passwords must be at least 10 characters with a number or symbol.
• Emailed sign-in and sign-up codes are six digits, stored only as a keyed hash (HMAC), valid for 10 minutes, usable once, and locked after 5 wrong tries.
• Two-step sign-in with any authenticator app (TOTP). Workspace owners can require it for every member, and platform administrators can be required to use it too.
• Single sign-on through your identity provider (SAML or OpenID Connect) and SCIM provisioning, so people are added and removed from your directory automatically. Sign in with GitHub is also available.
• Sessions use long random tokens; only their SHA-256 hash is stored on our side. The cookie is HttpOnly, SameSite=Lax and Secure. You can see your active sessions and sign-in history and sign out other devices; a disabled account can't get a session by any route.
• Brute-force protection: sign-in, code and password-reset endpoints are rate-limited per address and per account.

2.Access control inside a workspace

• Eight built-in roles (owner, admin, billing, developer, designer, editor, viewer, employee) and custom roles, with access that can be limited to particular modules, companies and branches.
• Every workspace's data is kept separate: each request is checked against the workspace and your role on the server, not just hidden in the interface.
• An audit log records important changes, sign-ins, exports and permission changes with who did them and when. Owners choose how long it is kept (at least 12 months, or for the life of the workspace).
• Our support team can look inside a workspace only when an owner grants time-limited access (up to 72 hours) with a reason; each grant is recorded in the audit log.

3.Protecting your data

• In transit: HTTPS/TLS for the app, API, published sites and webhooks, with HTTP Strict Transport Security (two years, including subdomains).
• At rest: credentials for payment providers and integrations, mailbox passwords and access tokens, and two-step sign-in secrets are encrypted with AES-256-GCM using a key held outside the database, and are never shown again after they are saved. Data is stored in a PostgreSQL database on our hosting provider's infrastructure, backed up on the schedule set for the platform.
• Exports: any list can be exported as CSV or Excel, and an owner can export the whole workspace as a machine-readable file at any time.
• Deletion: deleting a workspace is scheduled 30 days ahead (so a mistake can be undone), then everything in it is removed. Short-lived data such as sign-in codes and old request statistics is pruned automatically — see retention.

4.Application and network security

• Web application firewall in front of the app and API, with managed rules for SQL injection, cross-site scripting, path traversal, probes for sensitive files, known attack scanners, protocol abuse and command injection; per-address rate limits; blocking by IP address, range or country; and automatic temporary bans for addresses that keep tripping the rules. It can run behind Cloudflare, and the origin can be locked so that only Cloudflare can reach it.
• Cross-site request forgery protection: every state-changing request with a session cookie must come from our own origin, on top of SameSite cookies.
• Security headers: a Content Security Policy that limits where scripts, frames and connections can come from, X-Frame-Options: DENY and frame-ancestors 'none' against clickjacking, X-Content-Type-Options: nosniff, a strict Referrer-Policy, Permissions-Policy and Cross-Origin-Opener-Policy.
• Input validation: every API request body is validated against a schema and size-limited before it is used.
• Published sites run no third-party scripts of ours and send their own strict security headers. Emails shown in Mail are displayed in a sandbox.
• Code you run in the AI IDE executes in locked-down, isolated containers when that feature is enabled.

5.Payments

Subscription payments are taken by Razorpay and Stripe, which are PCI-DSS compliant payment providers. Card, UPI and bank details are entered with them directly, so Cloudesk never receives full card numbers, CVVs, UPI PINs or banking passwords. Every payment is confirmed on our server with the provider — signatures checked with our secret, and the amount, currency and order matched — before an invoice is marked paid. Webhooks from providers are verified the same way.

6.Operations, monitoring and incidents

• Platform administrators work through a separate console that can require two-step sign-in and an IP allowlist, and their actions are audited.
• Sign-in activity, firewall blocks and request volumes are monitored so unusual activity can be spotted and acted on.
• If an incident affects your data, we will notify workspace owners without undue delay, and report to CERT-In (within 6 hours for reportable incidents) and to the Data Protection Board of India and other authorities as the law requires.

7.Privacy and compliance

Our privacy practices are designed to align with India's Digital Personal Data Protection Act, 2023, the Information Technology Act, 2000 and its rules, the EU and UK GDPR and the CCPA/CPRA — see our Privacy Policy, Data Processing Addendum and Sub-processors.

To be clear about what we don't claim: Cloudesk does not currently hold ISO/IEC 27001 or SOC 2 certification, and PCI-DSS compliance applies to our payment providers, not to Cloudesk itself (we don't handle card data). If your organisation needs a security questionnaire answered, use the details on our contact page.

8.Reporting a vulnerability

If you believe you have found a security vulnerability in Cloudesk, please tell us privately through our contact page with “Security” in the subject. Include what you found, where, steps to reproduce it and the impact you expect. Our security.txt has the same details.

Please

• Test only against accounts and workspaces you own or have permission to test.
• Don't access, change, keep or share other people's data — stop and report as soon as you see any.
• Don't run denial-of-service tests, spam, social engineering or physical attacks, and don't degrade the Service for others. Automated scanners trigger the firewall; please keep their volume low.
• Give us a reasonable time to fix the issue before you disclose it publicly — we aim to acknowledge reports within 3 business days and keep you updated until it's fixed.

Our commitment

If you act in good faith and follow these guidelines, we will not pursue legal action against you or ask authorities to, and we will treat your research as authorised under our Acceptable Use Policy. We're happy to credit you once the issue is fixed, if you want. We don't currently run a paid bug bounty.