Messages sent through OneSignal's API and Automation are kept for around 30 days before being removed from OneSignal's servers.
All User Data and Messages sent through the OneSignal Dashboard 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.
See Exporting Data.
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.
OneSignal's SDKs are open source on Github.
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. However, if you use Proguard on your project this size will be reduced.
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.
Our Web SDK is 55 KB minified and gzipped. It is loaded asynchronously from our worldwide CDN with a long browser-expiry.
All OneSignal SDKs connect to our servers with HTTPS, and our REST API enforces the need for a REST API Key where it is needed.
Similar to all other software-as-a-service companies, every app that you create in OneSignal contains a public key (OneSignal app_id) and a private key (REST API Key).
iOS - OneSignal uses the TLS encryption for sending notifications as required by the Apple APNS specifications.
Android - OneSignal uses Google's GCM/FCM service, which uses the HTTPS protocol.
Steps to secure your OneSignal Account:
- 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 these steps to 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 the same as another site being compromised. You can check if this occurred using a site like https://haveibeenpwned.com/
Follow these steps to lockdown and reset your account:
While you are updating the password and keys, you can disable the app from sending using the "Disable App" button in Settings > Keys & Ids in your OneSignal dashboard.
Access your Accounts & API Keys section (top right of OneSignal Dashboard) to Reset Your Password. This will reset your User Auth Key as well, which is different from your REST API key.
If you use WordPress, make sure the password is updated and keep both passwords unique.
You can reset the REST key by going to you Dashboard > App Settings > Keys & Ids and click the link that says "Reset your REST API key?"
More details if needed in our Reset Your REST API Key guide.
You can Remove any Admin users on your account that are not part of the project anymore or who don't need access.
You can enable Two-Step Authentication within your OneSignal dashboard and require it for all users.
Make sure everyone on your team that has access to your account does the above steps.
Once finished, make sure to Re-enable your app in Settings > Keys & Ids.
If you believe that your REST API key has been compromised, please follow our guide to Reset Your REST API Key.
More details below on Locking down your account.
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 notifications if the device wasn't subscribed through valid means.
A user's own
player_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
player_ids of other users. This is because a
player_id on its own is sufficient to send a notification to that user's device. So the
player_ids belonging to other people should be kept secret.
Updated almost 2 years ago