Your Shopify app seems to be running without any issues. Your customers are getting notifications about back-in-stock products, and store owners are running their shops without any problems.
However, there could still be a security risk if an API endpoint exposes sensitive information, such as a Shopify Admin API access token, without checking who is requesting it.
If a merchant trusts your application with their store data, even just a single exposed credential may result in a security incident that will need to be investigated and resolved.
How Can a Simple Shopify API Endpoint Expose Sensitive Data?
Now let's say you've created a Shopify application that sends a message whenever a product is back in stock.
A consumer visits a site, looks for a certain product, finds out that it is not in stock, and leaves their email to get notified when the product is available again.
At that point, the app processes the request through an API endpoint.
Let's assume that a developer mistakenly returns the entire shop record rather than just some of its fields.
In addition to the domain of the shop and the notification settings, the API response can include a token for the Shopify Admin API.
If this endpoint is public, someone may be able to receive the token without logging in.
The problem is not the notification, but the information provided in the background.
This is an example of excessive information exposure, which is an issue developers must keep in mind while testing Shopify applications.
Why Is a Leaked Shopify Admin API Token So Dangerous?
An access token for the Shopify Admin API is an important part of an application’s ability to communicate with a merchant’s store. The token can have varying levels of access based on the permissions granted to the application.
An inventory management application may need permission to check details about products and keep track of stock levels.
This raises the question of what happens to the store if someone gets hold of the access token and uses it.
An attacker may be able to perform various actions with the same permissions. Access to the token may lead to the exposure of sensitive information or unauthorized changes.
The attacker would not necessarily need the merchant's password because the access token itself enables API authentication.
It’s also important to mention offline access tokens. With this sort of access token, applications are able to perform tasks even when the merchant is logged out.
Some tokens expire, while others can remain valid for longer periods. Either way, an exposed token can create a security risk.
This is why protecting tokens and limiting API permissions are both important. An app should only request the access it genuinely needs.
Sometimes the Problem Is Just a Few Lines of Code
Let's look at a simplified Django example.
Suppose your application has an endpoint that returns information about a Shopify store.
return JsonResponse({
"shop": shop.domain,
"access_token": shop.access_token
})
Can you spot the problem?
The response includes the store's domain, but it also includes its Admin API access token.
If an unauthorised person can call this endpoint, they may be able to obtain that credential.
Now consider this version:
return JsonResponse({
"shop": shop.domain
})
The endpoint will return only the data it needs to provide.
Just deleting the token does not make the API secure. Authentication and authorization requirements still need to be followed where necessary.
This small modification means that one unnecessary risk is avoided.
Developers should limit the fields returned by the API and avoid returning unnecessary database data altogether.
What Would a Penetration Tester Actually Check?
Identifying an exposed token is an important step, but Shopify app penetration testing also allows developers to detect a range of other security risks before they turn into an incident.
For example, there is a service that gives merchants information about their subscribers.
Requests could look like this:
GET /api/subscribers?shop_id=101
During an authorized assessment, a tester uses two different test stores and checks what happens if the identifier is changed.
Does the system reject requests for information belonging to other stores?
If the backend does not verify the requester's right to access store data and allows access to another store's information, the application has a vulnerability called Broken Object Level Authorization (BOLA).
This is particularly important for Shopify applications because they serve various merchants, and the same backend can be used to manage information for different merchants.
Other areas worth checking include:
Responses via public API: Do the various endpoints contain sensitive credentials, internal configuration details, or unnecessary information about customers?
Control of access: Is it possible for a user to access a resource owned by some other merchant by simply altering the identifier?
App proxy request: Does the backend verify the signature of the request from Shopify before trusting the forwarded parameters?
Webhooks: Are the incoming webhook HMAC signatures verified against the original request body?
API authorizations: Does a particular application ask for access that exceeds what its features require?
One important detail: verifying an app proxy signature doesn't replace checking whether a customer or merchant is authorised to access a particular resource.
These are different security checks, and both can matter.
Why Functional Testing Isn't Enough
Usually, testing the application features is considered a common practice when creating a Shopify app. Is the notification being received? Are merchants able to change their product data without any problems? Is the required information being produced by the app?
Functional testing means checking if the app works properly.
Penetration testing is used to check what happens if someone unauthorised tries to access the app data or perform actions.
For example, the notification endpoint may work correctly from a functional testing perspective; however, it may still leak sensitive data.
Some vulnerabilities can be detected by automated scanning. However, some tests require manual work to check things like cross-store authorisation and complex business integrations.
What Happens When a Shopify App Security Incident Occurs?
Finding out about a security breach is only part of what needs to be done. Developers have to understand what took place and how it might affect merchants.
For example, discovering an exposed Shopify Admin API token is not enough. Simply removing the token from the response will not solve the problem. The developer also has to invalidate the token.
An incident report should be prepared showing what happened and which stores and data were affected.
Developers must also meet Shopify's applicable incident reporting requirements. Penetration testing can help identify similar weaknesses in advance and prevent potential security incidents.
Five Things Shopify Developers Should Check Before Their Next Release
There is no need to wait for a security breach to check your application.
Evaluate API responses: Utilize the browser's developer features and API testing applications to check API responses for leaks of keys or configuration parameters.
Validate across numerous Shopify stores: Verify that one business could never manipulate data from another business by simply modifying the shop identifier.
Protect Admin API keys: Make sure to store credentials on the server safely and to avoid sharing them even through public code and URLs as well as HTML responses.
Verify the permissions and requests: You must verify whether your app requests permissions that it actually requires. You should also ensure that requests through proxies or webhooks are verified in accordance with Shopify’s requirements.
Be prepared for security incidents: In case you notice a security incident, you must analyze what happened, secure the affected environment, record the consequences and follow the necessary reporting requirements stated by Shopify. You can run regular penetration tests to identify vulnerabilities that might lead to security incidents.
Protecting Merchant Trust Starts With Testing
It is quite probable that many retailers utilise the same Shopify application. For example, when a single backend shared by many different retailers experiences a breach, there is a possibility that all the involved parties could be affected.
While fixing an issue at an endpoint can be a simple matter, restoring one’s reputation after a hack can be rather complicated.
This is why regular security audits are important.
Cyber Chief gives app developers a chance to reveal security weaknesses in their applications.
If the issues are complicated and related to authorisation or business logic, carrying out manual penetration tests may prove to be rather useful.
The aim of the process is not only to detect security threats beforehand but also to figure out how to react during a security incident.
In some instances, the only difference between a safe Shopify application and a compromised merchant credential can be the presence or absence of a specific field in the API response.
Watch the Cyber Chief on-demand demo to see not only how it can help to keep attackers out, but also to see how you can ensure that you ship every release of your Shopify app with the confidence of an armoured tank in a warzone.
How? Cyber Chief not only helps you find vulnerabilities across all components of your application, API and cloud stack. Most importantly, it also helps you fix these vulnerabilities in minutes, not days.
Cyber Chief has been built to integrate with the workflows of high-growth SaaS teams and that's why it offers:
Results from scanning your application for the presence of OWASP Top 10 + SANS CWE 25 + thousands of other vulnerabilities.
A detailed description of the vulnerabilities found.
A risk level for each vulnerability, so you know which ones to fix first.
Best-practice fixes for each vulnerability, including code snippets where relevant.
On-Demand Security Coaching from our application security experts to help you patch vulnerabilities in hours, not days.
Click the green button below to see how Cyber Chief works.