Security Guidelines

This document provides security guidelines for the services using the Kakao Platform.

1. Security settings in Kakao Developers

1.1. Set platform

Kakao platform only allows the apps with the registered Android package, iOS bundle, or site domain information to access the Kakao SDK (Software Development Kit). Register the app information in [Platform].

• Android SDK: Key hashes
• iOS SDK: Bundle ID
• JavaScript SDK: Site domain
  • To send a Kakao Talk sharing message, the shared URL also must be registered as a website domain. Otherwise, Kakao Talk fails to open the URL.

1.2. Set Redirect URI

To protect from attacks such as malicious redirects to other sites, Kakao passes an authorization code to the registered redirect URI only. Register a redirect URI in [Redirect URI], and pass the registered redirect URI for the value of redirect_uri. Only when the value of redirect_uri in the request matches the registered redirect URI, the authorization code is issued from the Kakao authorization server.

1.3. Use client secret code

Use a client secret code to enhance security when issuing an access token. Pass the client secret code through the client_secret parameter when calling the Get tokens or Refresh tokens API. Use the client secret code on the server-side (backend) only and keep it secret not to be revealed on the user's browser.

1.4. Set Allowed IP address

Set [Allowed IP address] to allow only the API requests sent from the predefined IP addresses.

1.5. Manage team members

To allow only the person registered as a team member to change the app settings, add a developer's account as a team member of the app. Since the Owner account has all permissions for the app, use a strong password for the Owner account not to leak the account information.

Set the role properly to grant different permissions to each team member depending on the usage purpose. For the Test app, manage registered team members to enhance the security since the test app is only available for the registered team members.

If the person with the Owner account has left the company, change the app owner. Remove the unnecessary team member by clicking [Expel].

2. Secure API calls

2.1. Keep app keys safe

The app keys are issued for each platform. The Kakao Platform verifies the API requests with the passed app key. In the case of the Admin key, use it only on the server-side (backend) not to be leaked since the admin key has all permissions.

If app keys are leaked, reissue the app keys with the Owner account of the app. Note that the reissue cannot be undone, and the old app keys are not available anymore.

2.2. Keep access token safe

Since an access token is used to make API calls, keep the access token secret not to be revealed. Use the refresh token on the server-side (backend) only.

We recommend setting the [Allowed IP address] to prevent others from calling an API with the stolen access token just in case the access token is revealed.

2.3. Use state parameter

To prevent Cross-Site Request Forgery (CSRF) attacks, use the state parameter when calling the Get authorization code API. The state value of the request for the authorization code will be sent to the redirect URI to verify the request's source.

Pass a unique and random value through state parameter for each Kakao Login request. And check if the value matches the value passed to the redirect URI. Note that the state value must be stored somewhere that other third parties cannot access, such as sessions or cookies that are protected under identical resource policies. Refer to RFC 6749 10.12.

2.4. Use prompt parameter

To enhance security, request for login regardless of whether the user is authenticated by presenting the Kakao Account Login screen. For this, set the prompt parameter to login for Get authorization code API.

2.5. Use nonce parameter

To use the ID token through OpenID Connect, use the nonce parameter when calling the Get authorization code API to protect from ID token replay attacks. Pass a unique and random value through nonce parameter to compare in the ID token verification process.

2.6. Allow firewall exceptions for API calls

To allow the API calls from the approved through firewalls only, add IP addresses of the Kakao API host used to call Kakao APIs, such as kauth.kakao.com and kapi.kakao.com.

To use callback functions such as Unlink callback, Kakao Talk Channel callback, and Kakao Talk sharing success callback, allow Kakao's IP addresses used to send callbacks.

To configure the preview for the service page in the Kakao Talk Sharing message, allow Kakao scrapping server's IP addresses to allow access to the service.

3. Security settings in system setup

3.1. Encrypt data in transmission

To protect all sensitive data transmitted to or from the application layer, comply with the following:

• Use HTTPS.
• Use a trusted certificate authority (CA).
• Use the latest version of Transport Layer Security (TLS) if possible. Refer to TLS versions supported by Kakao API server.

For the redirect URI used to get an authorization code and tokens, use HTTPS unless there is a special reason. Refer to RFC 6749 3.1.2.1

3.2. Encrypt data when storing data

Encrypt all sensitive data stored as a file or database.

3.3. Prohibit logging of sensitive data

Do not save the user's information received from Kakao in the system log.

3.4. Cautions when mapping existing members logged in with Kakao

If a user signs up through the signup process of the service, and the user is identical to one of Kakao Login users, map the user onto the existing user data by complying with the following:

• After users sign up for the service through Kakao Login, identify the users by using their service user IDs that are provided through the Retrieve user information API (/v2/user/me).
• A service user ID is a length-variable number between 1 and 9,223,372,036,854,775,807 with a Long type. Implement a mapping functionality by considering that the number length may vary in the range.
• Identify users by using Connecting Information (CI) or email. When using an email, map users only after the user verification is completed. When using a phone number, do not simply compare strings because the owner of a phone number may change.
• It is highly recommended to implement a process that asks a user to log in with the existing account before mapping to ensure that the user is the owner of the account.

3.5. Cautions when implementing functions

To protect users' personal information and to securely use the functions provided by Kakao Developers, comply with the Operating Policy.

• In accordance with Article 1 (Obligation of Service Users), Paragraph 2 of the Operating Policy, provide a menu to delete an account from the service. When a user deletes their account, delete the user's personal information in an irrecoverable way. The service user IDs that are provided through the Retrieve user information API (/v2/user/me) are also personal information that needs to be destroyed.
• To keep service user IDs for a certain period, leave the basis for storage in terms of service or privacy policy and obtain the separate user's consent.
• When a user deletes an account, request the Unlink API to withdraw the user's consent for the provision of personal information.
• To synchronize the withdrawal of consent for the provision of personal information and the deletion of personal information in the service, it is recommended to delete an account from the service by receiving the Unlink callback from Kakao when the unlink occurs in the Use Your Account of the Kakao Account Management page.

3.6. Security Event Subscription

To keep users' personal information up to date, use Security Event Subscription providing users' security status changes.

• Enable the subscription for required security event types and set a callback URL in [Security Event]. Event information will be delivered in JWT(JSON Web Token) format.
• Security events are categorized in three categories of OAUTH(Kakao Login), RISC(Risk Incident Sharing and Coordination), and CAEP(Continuous Access Evaluation Protocol). To use RISC and CAEP categories, set a consent item and request permission through DevTalk.
• Implement a system that handles security event information complying with each security event type's required or recommended security action. Of these, it is recommended to subscribe to User Unlinked and User Scope Withdraw event types in the OAUTH category to delete personal information provided to the service.

3.7. Keep SDK version up to date

Kakao services, including Kakao SDKs, provide security updates. To strengthen security, check the latest version of Kakao SDKs periodically and use the latest version if possible.

3.8. Ask access permission for least data

Set consent items for the least data only required for the service, which a user will consent to when logging in.

4. Brand

4.1. Input correct information

To avoid phishing or misleading users into believing another service provides the app, register the app icon, app name, and company name that corresponds to the actual service in Kakao Developers.

4.2. Follow Kakao brand guidelines

When integrating Kakao Login into the service, comply with Design Guide so that users can recognize that they will sign up through Kakao Login.

We prohibit Kakao trademark infringement. Do not alter the app name, icon, and company name to something that may mislead users into believing your service is a Kakao service or partner. For example, do not add "for Kakao" to the app name or company name.

5. Security incident response

5.1. Prevent additional damage by reissuing app keys

If your app's app keys are revealed, reissue the app key. Note that the reissue cannot be undone, and the old app keys are not available anymore. Replace the old app keys applied in the service app or website with the new app keys to make Kakao API calls. Otherwise, your API request fails.

5.2. Report security vulnerability

Please report any security vulnerabilities in Kakao services through pf.security@kakaocorp.com. For inquiries about the methods or ideas to enhance security for the services using Kakao Platform, contact us through DevTalk.