Leaked Square Access Token? Revoke It, Review Orders

A Square access token lets whoever holds it call the Square API as the seller it was issued for, with the permissions granted to the application. In production that can mean reading payments, orders, customers, catalog and inventory, and, depending on the scopes, creating or refunding payments. A leak is therefore both a financial risk and a customer-data risk. Revoke the token first, then audit what it could reach.

Check your GitHub account for leaked secrets — free

Provider: Square
Severity: High
Impact: Payments and customer data
Checked live by LeakWatch: No

What a Square access token looks like

This guide covers the older production access token, which starts with sq0atp- followed by 22 characters:

sq0atp-…XXXX   Square access token, legacy format (masked, 22 characters after the prefix)

Square now issues production tokens that start with EAAA instead, and those are covered by a separate rule, as are the personal access tokens beginning sq0idp- and the OAuth application secrets beginning sq0csp-. The steps below apply to all of them in the same way. Sandbox tokens also begin EAAA, so a sandbox token in a public file is much less serious than a production one, though you should still replace it. The variable that usually holds a token is SQUARE_ACCESS_TOKEN.

How Square access tokens get leaked

Hardcoded in a point-of-sale integration. A script that syncs sales, inventory or customers with the token typed in.
Committed environment files. SQUARE_ACCESS_TOKEN in a .env file or deployment configuration.
Front-end code. A checkout page or app that calls the API directly with the token instead of using the application ID and a server-side call.
E-commerce plugin exports. A site backup or plugin configuration that stores the token.
Sample code and support threads. An SDK snippet from a tutorial, with a real token in place of the placeholder, pasted into an issue or a screenshot.

What to do in the first hour

Open the Developer Console (see the link below) and find the application the token belongs to. Check the Credentials page, where production and sandbox credentials are listed separately.
Revoke or rotate the token. For a personal access token, replace it from the application’s credentials page. For tokens issued through OAuth to other sellers, revoke the token through the OAuth revoke endpoint described in Square’s documentation, and have the seller authorize again.
Deploy the new credentials to your servers and test one read call. Store them in a secret manager.
Audit payments and refunds. Review recent payments, refunds and any gift cards or invoices created since the exposure that you do not recognize.
Audit orders, catalog and customers. Look for orders, catalog changes or customer records created, changed or exported without your knowledge. Pay attention to webhooks subscriptions too.
Check webhook subscriptions and team members. Make sure the webhook endpoints are yours, and review the application’s team and sellers who authorized it.
Assess customer data. If customer records may have been read, you may have notification duties. Talk to Square support and a qualified adviser, then clean the repository. See I accidentally pushed an API key to GitHub.

Not sure what else leaked from the same repository? Run a free scan.

Not sure what else leaked? Run a free scan.

Revoke it at Square

Square credentials are managed in the Square Developer Console, after you sign in with the account that owns the application. Open the application, go to its credentials, and replace the exposed token. For OAuth tokens, Square documents a revoke call that invalidates a token or all tokens of a seller. A person has not confirmed the exact menu wording for this guide, and the console can change, so if what you see differs, look for the application’s credentials section, and follow Square’s developer documentation.

How LeakWatch detects it

The rule is called Square Access Token. It recognizes the lowercase prefix sq0atp- followed by exactly 22 letters, digits, dashes or underscores, with word boundaries on both sides. A prefix in capitals, a shorter or longer body, or the sq0csp- prefix of an OAuth secret is not reported under this rule; the EAAA and sq0idp- formats have their own rules. The severity is high, and the impact class is payment data. This type is not checked live: LeakWatch does not send any request to Square with the token it found.

LeakWatch detects this format but does not check it live: it can tell you the key is exposed, not whether it still works. Assume it does until you have revoked it.

FAQ

Can someone take money with this token?

It depends on the scopes granted to the application. A token with payments scopes can create payments or refunds, so review those first. A read-only token mainly exposes data, which is still serious.

My leaked token started with EAAA. Is this guide still right?

Yes, the steps are the same. That format has its own detection rule, but the revocation and audit work is identical.

Is a sandbox token a problem?

A sandbox token cannot touch real money or real customers, so the urgency is much lower. Replace it anyway and check that no production token sits in the same file.