L
L
Liudar2017-10-13 16:17:39
Android
Liudar, 2017-10-13 16:17:39

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

5 answer(s)
V
Vyacheslav Uspensky, 2017-10-13
@Kwisatz

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.

X
xmoonlight, 2017-10-14
@xmoonlight

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.

N
Night, 2017-10-13
@maxtm

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.

C
cicatrix, 2017-10-13
@cicatrix

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).

D
Developer, 2018-05-27
@samodum

There is only one way here - to screen requests through your own server, from where you can send requests to the paid API
Mobile application -> your own server -> paid API

Didn't find what you were looking for?

Ask your question

Ask a Question

731 491 924 answers to any question