Data and Security FAQs
Common questions about OneSignal's data handling and security
Data Questions
Common questions around data storage and collection. See Handling Personal Data for recommendations on user data storage.
Where are OneSignal's Data Centers Located?
OneSignal's data is stored in Netherlands in a datacenter managed by Google Cloud Platform (GCP). Details on our move in this blog post.
How long is data stored inside OneSignal?
Messages sent through OneSignal's API, Journeys and Automated Messages are kept for around 30 days before being removed from OneSignal's servers.
All User Data and Messages sent through the OneSignal Dashboard Create Message forms are kept for the lifetime of the OneSignal App or unless manually deleted.
Notification History is the list of devices that were sent or clicked the push. This is available for 7 days.
Does OneSignal use cookies?
OneSignal's SDK does not use cookies. We do use Local storage and IndexDB.
You may see the cookie __cf_bm
in your browser attributed to OneSignal. This cookie is set by Cloudflare and is used to fight bots. The EU cookie law explicitly allows cookies that implement system features without user consent. Cloudflare explicitly mentions these cookies in their own policy under Strictly Necessary; including that they cannot be opted out of. For more details, see this GDPR explainer on not needing explicit user consent for Strictly Necessary cookies.
What data is collected by the OneSignal SDK?
See Data Collected by the OneSignal SDK.
How do you recommend handling user data in OneSignal?
How do I export data from OneSignal?
See Exporting Data.
Is OneSignal COPPA compliant?
OneSignal is certified with the Families Ads Program as of January 10th 2022.
COPPA is the responsibility of the publisher to maintain. However, OneSignal provides an easy solution for gathering User Consent before collecting data and prompting for push. More details on how to properly handle this interaction can be found in this article: How to Implement COPPA Compliant Push Notifications in Kid Directed Apps.
Is OneSignal HIPAA compliant?
Yes! Our work in achieving SOC 2 certification has also helped us in our goal to achieving HIPAA compliance. For those not aware, the Health Insurance Portability and Accountability Act (HIPAA) is a federal law that regulates how companies and healthcare providers handle protected health information (PHI) to ensure proper data security. We are happy to say that we now support a core aspect of HIPAA compliance by offering a Business Associate Agreement (BAA) to Enterprise Plan customers.
How can I or my users opt-out (unsubscribe) from web push notifications?
See Unsubscribe from Notifications.
How large are the OneSignal SDKs?
OneSignal's SDKs are open source on Github.
Native Android SDK
Our Native Android SDK is currently 190KB and, like most Android SDKs/Plugins, it depends on the Android Support Library v4 and Google Play services library which may add 1 to 2 MB if they are not in your project already. For v5 of our SDK, expect ~600kB added to your app's size. However, if you use Proguard on your project this size will be reduced.
Native iOS SDK
Our Native iOS SDK is a 3MB download. However, if you build your app with bit code turned on, it will only add around 500KB to your app's size.
Web SDK
Our Web SDK is 55 KB minified and gzipped. It is loaded asynchronously from our worldwide CDN with a long browser-expiry.
Security Questions
How secure is OneSignal?
All OneSignal SDKs connect to our servers with HTTPS. Our REST API enforces a TLS 1.2+ connection and the need for a REST API Key where it is needed.
How to lock down or secure my OneSignal account?
Steps to secure your OneSignal Account:
- Disable your apps within Settings > Keys & IDs > Disable App
- Use Two-Step Authentication and enable it for all users with access to your account.
- Remove Administrators that do not need access to your account. Multiple people should also not share a single account. You should have 1 email associated for each person.
- Do not publish your REST API Key or User Auth Key. These keys should not be placed anywhere publicly accessible like Github or within your app/site.
- If you believe your account is already compromised follow the below steps to reset your account.
Reset your account
Make sure your OneSignal REST API Key and User Auth Key did not get published within your app/site or openly, like on Github. Also, make sure your email and password used for OneSignal is not easily guessable or the same as another site that has been compromised.
1. Reset your User Auth Key
Login to onesignal.com and go to Account & API Keys in the bottom-left corner.
Navigate to User Auth Key > Generate New User Auth Key.
Select Yes, generate a new one
2. Reset your password
In Account & API Keys enter a New Password and Confirm Password. Then Submit.
3. Reset your REST API key and keep in secret.
In your App, navigate to Settings > Keys & IDs and select Generate New API Key for all apps.
4. Remove old Admin Users
Remove Administrators that do not need access to your account. Multiple people should also not share a single account. You should have 1 email associated for each person.
5. Enable 2 factor Authentication
You can enable Two-Step Authentication within your OneSignal dashboard.
Account Secure
Make sure everyone on your team that has access to your account does the above steps.
What happens if a "bad actor" gains access to my OneSignal REST API Key?
If you believe that your REST API key has been compromised, please follow our guide to Reset Your REST API Key.
More details above to Reset your account.
What happens if a "bad actor" gains access to my OneSignal app_id?
If someone was to gain access to your app_id
through your application or site, they could technically add a new device record. However, that record cannot receive push notifications if the device wasn't subscribed through valid means.
You can prevent users from impersonating one another with Identity Verification.
What happens if a "bad actor" gains access to a OneSignal subscription?
A user's own subscription_id
is public to that user, and discovering it is generally harmless. It can be used to view and update tags and other data about the user's subscription. For this reason, tags should not be used for either authentication or the storage of sensitive data and personally-identifiable information.
Users of your application or service should not be given access to the subscription_id
s of other users. This is because a subscription_id
on its own is sufficient to send a notification to that user's device. So the subscription_id
s belonging to other people should be kept secret.
You can prevent users from impersonating one another with Identity Verification.
Updated 7 months ago