Your Shopify app was breached: the first 24 hours

You have found an unknown admin session, a database export nobody ran or a message saying merchant data is for sale. The instinct is to patch something immediately and find out what happened later. That instinct can destroy the evidence you need, and it can use up a notification deadline while you do it.

The first day has three jobs: stop the damage, keep the evidence and tell the right people on time. They compete with each other, so the order matters.

This article is a practical sequence for a Shopify app team. It is not legal advice. Your duties depend on your contracts, your role for each kind of data and where your merchants and their customers are, so bring in a lawyer early.

The short version

• Shopify’s terms require notice of any actual or suspected breach of Merchant Data immediately, and no later than 24 hours after you become aware of it.
• Do not wait for a finished investigation. Send what you know, mark what you do not know and update it.
• Capture evidence before you rebuild or delete anything. If an attacker is active, stop them first and record what you changed.
• Assume that any secret the compromised system could read is compromised.
• If you act as a processor for merchants, GDPR requires you to tell them without undue delay. They may then have 72 hours to notify their regulator.
• Never write “no data was accessed” unless your logs can prove it.

The deadlines that apply

More than one clock may be running, and they do not all start at the same moment.

The word that matters most in the first row is suspected. Under the EDPB’s breach notification guidelines, a GDPR controller becomes aware when it has a reasonable degree of certainty that personal data was compromised, and it may take a short period to investigate first. Shopify’s wording is stricter, because it covers suspicion as well. A team that waits for certainty can meet the GDPR standard and still miss the Shopify one.

Many apps act as a processor for some data, such as a merchant’s customers, and as a controller for other data, such as their own account records. Check your privacy policy and merchant terms instead of assuming one role. The list above is not complete either: other countries and US states have their own rules, and your contracts or insurance policy may add more.

Hour 0 to 1: take control of the response

Name one person in charge. Someone has to decide, even when the information is incomplete. In a small team this can be the founder. Give a second person the job of keeping the timeline.

Start the clock on paper. Record when the issue was first noticed, by whom and how. Shopify’s deadline runs from awareness, so this timestamp matters. Use UTC throughout, and note who did what from this moment on, including your own changes.

Move to a clean channel. If email, chat or a developer laptop might be affected, the attacker may be reading along. Use a separate channel and limit it to the people who need to know.

Do not destroy anything. No rebuilding servers, no dropping suspicious tables, no clearing logs, no force-pushing over a malicious commit. Fixing what looks wrong is exactly how evidence disappears.

Hour 1 to 4: preserve evidence, then contain

Normally you capture first. If data is actively leaving or an attacker is logged in right now, containment comes first: cut the access in the least destructive way you can, and write down what you did.

Capture what you can quickly:

• Disk and database snapshots of the affected systems, before any cleanup.
• Application, web server, database, authentication and cloud audit logs.
• Deployment history, CI runs and recent changes to admin users, keys and environment variables.
• Queues, job history and object storage access logs.

Then look at retention. Log platforms and cloud services often delete data on a short rolling window, so extend retention or export now. The record of the first intrusion may be the oldest and most exposed to deletion. Keep the copies somewhere the compromised credentials cannot reach.

What to rotate

Rotate according to what the attacker could reach, not only what you can prove they used. The usual starting point is:

One decision needs care. Shopify’s normal rotation avoids downtime: you add a new secret, move all tokens to it, then revoke the old one. But Shopify also says that if a secret is actively being misused, you should revoke it immediately, even though merchants lose access until the new secret is in place. If a stolen secret is only suspected, the staged path may be reasonable. If you can see it being used, take the outage.

An access token pinned to the old secret stops working when you revoke that secret, so the job is not finished until the revocation has happened. Also, remember what webhooks do during this period: they stay signed with the oldest unrevoked secret, so your verification must accept both secrets until then.

If the code path itself is the hole, disable the feature or put a block in front of it before you work on the full fix. A narrow temporary block is usually better than taking the whole app offline, and much better than a rushed patch that nobody has tested.

Hour 4 to 12: establish the scope

You will not have full answers today. Aim to know enough to give an honest first report:

• How did they get in? Note whether this is proven or a working theory.
• When? Find the earliest evidence, and do not assume the first alert was the start.
• What could they reach? Compare that with what the logs show they actually accessed.
• Which stores? Get a list, and ask whether the access crossed from one store to another.
• Which data? Separate customer names and emails, addresses, order data, tokens and merchant account data.
• Did they use stolen tokens? Look for Admin API activity your app did not generate, and changes in merchant stores.
• Is it still happening? Confirm that the access you closed was the only access.

Keep two columns throughout: what the evidence shows and what you do not know. “We have no evidence of access” and “we have evidence there was no access” are very different statements. If the database logs only go back seven days and the intrusion may be older, the honest answer is that you cannot tell.

This is where an access log pays for itself. Shopify’s level 2 protected customer data requirements include keeping one, because without it the affected-data question often has no answer. The worst case is then the one you must report.

Hour 12 to 24: notify Shopify

Do not treat this as the last step. If the evidence is strong, or if you are close to the deadline, send it earlier. The terms direct you to report the issue to Shopify Support through the partner help page. They also expect you to fix the breach, investigate it, reduce further harm, answer Shopify’s questions and keep reporting progress, all at your own cost.

A first report does not need a root cause. It needs facts and clear labels:

Subject: Suspected Merchant Data breach - [App name] (App ID: [ID])

When we became aware: [UTC timestamp]
What we observed: [what triggered this, in plain terms]
Status: [suspected / confirmed] [contained / ongoing]

Known so far:
- Systems affected: [...]
- Data possibly affected: [types]
- Stores possibly affected: [number or "not yet known"]
- Window: [earliest evidence to containment, or "not yet known"]

Not yet known: [the main open questions]

Actions taken: [containment and rotation, with UTC times]
Next update: [date and time]
Contact: [name, email, phone]

Have your lawyer read it if that does not risk the deadline. Keep the wording factual, avoid guesses about the attacker and avoid conclusions you may need to withdraw.

Telling merchants

The merchant is usually the one responsible to its customers and regulators, and it can only act on what you tell it. If you are a processor, GDPR requires you to tell it without undue delay. You do not decide whether its risk is high enough: the EDPB notes that a processor does not need to assess the risk before notifying, because that assessment belongs to the controller.

Your message should say what happened, when, which of the merchant’s data is involved, what you have done, what the merchant should do and how to reach you. Article 33(3) lists the information a controller will need for its own report, so include the categories and approximate numbers of people and records where you can.

Tell affected merchants directly, and give them a store-specific answer if you can. Agree the wording with your lawyer and align it with what you told Shopify, because the same facts will be compared.

Mistakes that make it worse

• Waiting until you are sure. The clock for suspected breaches does not wait for confirmation.
• Rebuilding first. A clean server with no evidence leaves you unable to answer which stores were affected.
• Rotating only the secret you know leaked. Whoever read one value from the environment could read them all.
• Rotating before removing the attacker. New credentials are stored somewhere the attacker can still reach.
• Understating the scope. A later correction costs more trust than an honest “not yet known”.
• Patching the one endpoint. The same pattern often exists elsewhere, and it may not be the only way in.
• Closing the incident too early. Watch for returning activity, and test the fix independently.

Before you need this

Most of the first day depends on decisions made earlier. Shopify already lists a security incident response policy among its level 2 requirements for protected customer data, covering items such as severity scales, roles, escalation paths and evidence collection. A useful minimum:

• One page with roles, contacts, and the deadlines from the table above.
• A saved copy of the report template.
• Centralized logs, kept for longer than an intrusion is likely to stay unnoticed.
• An up-to-date list of every secret, where it lives and how to rotate it.
• A rotation rehearsal on a development app, so the first attempt is not during an incident.
• A monitored emergency developer email address.
• Your data roles documented for each type of data, with a lawyer you can call on short notice.

First 24 hours checklist

• Incident lead named and awareness time recorded in UTC.
• Timeline running, and a clean communication channel in use.
• Snapshots and logs copied out of reach, and log retention extended.
• Active attacker access removed.
• Cloud and CI credentials rotated before application secrets.
• Client secret rotation decided: staged, or immediate if actively misused.
• Tokens, database passwords, private keys and third-party keys rotated.
• Known and unknown facts recorded separately.
• Scope estimated by store, data type and time window.
• Shopify notified within 24 hours, with the next update scheduled.
• Merchant, regulator and customer duties reviewed with a lawyer.
• Any merchant notice checked against what Shopify was told.

After the first day

Once the immediate response is over, the questions change: what exactly happened, is the fix sound and what else could have been reached? If Shopify has asked for an incident report and independent testing, our Shopify App Incident VAPT covers the incident path and the agreed attack surface, with a report draft built from your records. It states what the evidence establishes and what remains unknown. If you have already fixed confirmed findings and need independent evidence, see our Shopify app security retest.