Here’s some of the practices, standards, and methods we use to keep your data, and user’s data secure.

To help prevent XSS attacks, all authentication pages require a callback URL to be set in Kinde. Authentication does not work correctly without them. Our application will check the callback URLs and parse out the domain for an origin check.

Kinde protects against CSRF attacks by using and recommending the state parameter as part of an auth token. All state changing requests generate a CSRF tokens server side, which are validated on the backed, and cookies are set to sameSite strict.

To prevent clickjacking attacks where a user’s personal information or credentials may be stolen by hidden iFrames, use Kinde’s hosted pages for authentication. Hosted pages have protections in place such as such as strict CSP and security headers to prevent itself from being embedded as an iFrame.

Kinde controls and hosts the authentication pages, so the risk for protecting pages is assumed by Kinde rather than you.

Kinde provides a baseline password protection policy for any customer who wants to include password authentication in their product.

• 8 character minimum
• No complexity requirements
• Blocking of 10,000 most common passwords
• 5 incorrect attempts locks account out for 5 minutes

Note that Kinde recommends, where possible, not using passwords for authentication and instead using passwordless or social integrations. If using passwords for authentication, we recommend adding multi-factor authentication as an option for users.

Kinde has implemented an application level rate limit and throttle. This helps protect our shared infrastructure and our customers from excessive network traffic that could lead to an outage. Our rate limits are tuned based on the type of traffic, such as API, admin pages, or general auth usage, and will limit the number of connections from an IP in a short space of time. This generally covers all interactions for our service.

Kinde implements a method of fingerprinting during the authentication flow to block the transfer of sessions between different browsers that could lead to session highjacking.

Kinde enforces strict TLS versions and ciphers across it’s public facing websites and API endpoints.

TLS 1.3

• TLS_AES_128_GCM_SHA256
• TLS_AES_256_GCM_SHA384
• TLS_CHACHA20_POLY1305_SHA256

TLS 1.2

• TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
• TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256
• TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
• TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384

Kinde uses various techniques to help prevent the execution of unknown third party scripts and the injection of malicious third party scripts by using XSS protection and CSP.

Kinde’s server rendered application encodes output by default, which prevents most opportunities to inject HTML. The Content Security Policy configured across our webpages prevents the execution of inline and third party scripts.

Kinde was implemented a web access firewall (WAF) across all of our public-facing websites and API endpoints. This blocks known malicious traffic patterns and high threat IP addresses.