Kloudle Security
Kloudle was founded on the promise of providing customers security insights into their cloud infrastructure. One of the ways, we keep that promise is by holding ourselves to the highest industry accepted standards of security, because we believe trust in the cloud security industry can only be estabilished by ensuring our own resources and the product itself are kept secure.
Apart from following best practices and coding standards, Kloudle also undergoes an extensive vulnerability assessment and a penetration testing exercise periodically, both internally by teams who are certified security experts and by an external certified vendor.
We also dog food our own product and use Kloudle to monitor our various cloud resources for security and compliance violations.




We are SOC2 Compliant
All code, product infra, team members and processes are verified and accepted as part of the SOC 2 requirement. All internal processes are reviewed periodically for compliance.
Access Control for Account Access
We use Google and Microsoft SSO for user account access so that we never store your login credentials. Your accounts are then protected by the standards established by the SSO providers.
Data Encryption at Rest and Transit
All data stored in the application, including any cloud credentials and metadata, is encrypted using SSE. In transit data is protected by a RSA 2048 bits SSL/TLS connection.
Secure Cloud Credential Storage
No human has access to the cloud credentials that you onboard and are only read by authenticated and authorized cloud functions via a cloud native secrets manager, as part of the product.
Stringent checks and coding Standards
Our devs adhere to coding best practices and secure coding standards. Every single PR is internally verified, code checked for bugs and then merged before being released.
Founders with a Hacker mindset
The Kloudle founders are industry veterans in cybersecurity with over 35 years of field experience between them, due to which security paranoia is built into the DNA of the product.
Apart from following best practices and coding standards, Kloudle also undergoes an extensive vulnerability assessment and a penetration testing exercise periodically, both internally and by an external certified vendor. We also dog food our own product and use Kloudle to monitor our various cloud resources for security and compliance.
Frequently Asked Questions
-
No. Kloudle does not have a Bug Bounty program, private or public. Neither do we offer swag for unsolicited security reports.
-
Although, active testing of Kloudle's app and infrastructure is not permitted, if you think you have found a security issue, you can report it in the following manner based on where the issue is present:
- 1. If the issue is found in any kloudle owned online property, please send an email to security@kloudle.com
- 2. If the issue is in the product, then you can raise the issue with our Engineering team directly through the app's feedback feature.
-
We do not consider vulnerability reports which do not include careful manual validation - for example reports based only on automated tools and scanners or repots that describe theoretical attack scenarios without proof of exploitability. This is a non-exhaustive list of reports that we don't consider to be a security problem across the website, the app and other KLOUDLE domains:
- Exposed free trial
- Bugs within the sandbox of the free trial (these are part of the product)
- Any language, grammar or technical inaccuracy of Kloudle's findings or claims
- Expired domains, SSL/TLS certificates or exposure of information via SSL/TLS certificate's Subject CN or via Certificate Transparency Logs.
- Reports of broken links
- Reports of unclaimed social media accounts
- Disclosure of known public files or directories, (e.g. robots.txt)
- Directory Listing
- Images accessible via CDN and directly on the site
- Cloud Account identifier information via JS/Images/Screenshots/Social Media/static files etc.
- Security issues in third-party integrations within Kloudle (chat bot for example)
- Caching related issues
- Software version disclosure (disclosing the server is Apache or nginx etc.)
- Service Banner identification issues (SSH version was identified etc.)
- Descriptive error messages or headers (e.g. stack traces, application or server errors)
- Full path disclosures due to error pages or verbose stack trace information
- Missing CAPTCHA
- HTTP 404 or other non-200 code pages
- Exposed admin login panels
- Leaked Kloudle email addresses
- Metadata in PDFs, images etc.
- Any automated scanner reports that are not validated
- Static content over HTTP or "Mixed content" issues
- Attacks requiring MITM or physical access or control over a user's device.
- Modification of response content to display frontend app
- Missing HttpOnly or Secure flags on cookies
- Missing security headers in responses
- Information in JWT being disclosed in header and payload sections
- Session timeout related bugs
- Relaxed CSP
- Internal IP disclosure
- Cookie valid after logout
- Cookie valid after password change
- Username/Email enumeration via login page or registration page status/error messages
- Security bypasses in SSO when the bypass is with the Identity Provider (Google Auth bypass for example)
- 2FA/MFA bypass in auth provider when auth provider is not Kloudle
- Social Engineering (phishing, attempts to steal cookies via fake login pages etc.)
- Denial of service attacks (DDOS/DOS)
- Issues related to rate limiting and Brute force issues on any API across the website and app
- JS/webserver/framework or previously known vulnerable libraries
- Reports of Keys or Tokens in JS unless it can be proven that the discovered can be exploited
- Unminifying JS, reverse engineering and unobfuscation of client side JS
- Same site scripting
- Self XSS
- Clickjacking anywhere on the site or the app
- Cross-Site Request Forgery (CSRF) on unauthenticated forms or forms with no sensitive actions.
- Open Redirects
- Vulnerabilities affecting outdated and unpatched browsers
- Public zero-day vulnerabilities
- CSV/Formula Injection
- Tab nabbing
- Spam/Flooding - Email, SMS or any other type of data flooding
- Sub domain takeover issues without proof of concept
- Reports related to password strength
- Reports related to information disclosed in GET parameters
- Content Spoofing and Hyperlink Injection
- Host header attacks
- Issues with SPF, DKIM or DMARC records for kloudle.com or any other kloudle domain
- Flash or Silverlight related security issues
- GitHub public repositories
Also, please use the CVSS 3.1 Calculator at https://www.first.org/cvss/calculator/3.1 to compute severity and only consider sharing of issues that are rated 8 or higher. -
Yes. We encourage you to encrypt any sensitive information that you send to our security email address using GPG.
Please use this key GPG Key.
Key fingerprint - D404 4F85 4E73 7CAB 44FD EC95 7FD1 15ED BFB0 8DC6 -
Please send your queries to security@kloudle.com. We respond to security related queries only on this email. Expect a turnaround time of at least 3 to 4 business days. For any other information related to the product, signup, subscription, billing etc., please use our contact page.