Square OAuth secret

ID

square_oauth_secret

Severity

critical

Vendor

Square

Family

OAuth secret

Description

Square is a popular financial services and digital payments platform.

It provides payment processing SDK/API, which uses different authentication and authorization mechanisms using access tokens.

Before an application can access a Square merchant’s data, the merchant needs to give permission to the application. The Square API uses the OAuth 2.0 protocol for this.

There are two OAuth flows, code or PKCE. The code flow typically needs a confidential client to pass the client_id and client_secret when redeeming an authorization code from Square. The PKCE flow is for public clients like mobile apps that cannot safely store secrets in the application, such as mobile applications, single-page applications, and native desktop applications. But at the end someone must call the Authorize endpoint passing both the client_id and client_secret.

Security

Leaking an OAuth secret is a potential security issue. It can allow an attacker to access the Square API without authorization. Leaking the OAuth secret for the is a potential security issue.

Examples

Imagine that the Square OAuth secret is accidentally disclosed when this .env file is committed to a source control repository:

# Square OAuth secret
square_application_id=sq0idp-jqt6...D79g
square_application_secret=sq0csp-GRH90RYo...GWXQs

Mitigation / Fix

  1. Follow your policy for handling leaked secrets, which typically require replacing the leaked OAuth secret with a new one. For that, login in the Square Developer Console, select the target application, click OAuth on the left menu, choose between Sandbox / Production environments, click the Application Secret - Replace link, and then click the Replace button in the confirmation dialog. Take note of the regenerated secret, as you will need to change the leaked secret value with this new one.

  2. Remove the leaked Square OAuth secret from the source code or committed configuration file. Environment variables, local files or secret vaults could be used for passing the secret, instead of hardcoding the value, as documented in How to Prevent Hard-Coded Secrets.

  3. Check access logs to ensure that the secret was not used by unintended actors during the compromised period.

You should consider any sensitive data in commits with secrets as compromised.

Remember that secrets may be removed from history in your projects, but not in other users' cloned or forked repositories.

Reference