Answer the question
In order to leave comments, you need to log in
How to secure the paid content service API?
Good afternoon.
A question arose regarding protection against unauthorized access to content received by a mobile application through the API. We are talking about paid subscriptions to media content (articles, videos, etc.) in a mobile application WITHOUT registration (no account, authorization, etc. Only subscription purchases). It is clear that you need to at least wrap everything in https. It is clear that you need to verify the purchase ID through Google InApp Billing.
Yes, you can protect the copying of text from the application, saving pictures and videos, you can even prohibit screenshots. But the APIs remain bare. It is enough to see where the traffic goes, with what keys and pull everything out with curl. There was an idea to sew a key or certificate into the application itself, but, as far as I understand, picking it out from there on a rooted device will not be difficult.
The question is: how is this protection implemented correctly? After all, there are many similar services, and it is logical to assume that this issue is resolved there.
So how do you protect content from being leaked via the API?
Answer the question
In order to leave comments, you need to log in
Please remember: the client is in the hands of the enemy. Always. There are no exceptions. Any protection can be only on the server, on the client - only visibility.
Encrypt the content being served via RSA between the server and the application. (SSL/non-SSL - we don't consider this now!)
2. Use payment data when encrypting data on the server.
3. Change the key on each request based on the current session's packet number, time, random number, etc.
4. Give content in portions with different encryption - prefetch/segmentation.
5. Update the internal encryption protocol at least once every 1-2 months.
There is no 100% protection on the client that would not allow content to be saved.
For that - it is possible to complicate it to unrealistic labor costs.
But is protection by purchase ID not enough?
curl will not be able to pull out more than what was bought.
If you don’t want the purchased items to be pulled out somehow, except in the app itself, try inserting once-tokens, the generation of which will only be known to your app.
This will make it so that all requests are valid only once.
Of course, there is a case when the request does not reach the server, and then it is executed by curl, but this is already from the category of paranoia.
The complexity of protection should be commensurate with the value of the protected content.
Give the client a token - a meaningless guid, let the API present it, get the next portion of content, change the token after a period of N (minute, hour, day, week).
Didn't find what you were looking for?
Ask your questionAsk a Question
731 491 924 answers to any question