Skip to main content

How to prevent net viewing bandwidth quota abuse in native apps?

Flaviu Ratiu
Edited

Hi.

I'm having difficulties figuring out the correct approach for preventing the following scenario:

In my understanding, if I expose a cloudinary image url to the client, that means a malicious user could make any number of requests for that image, thus being able to endlessly increase my Net Viewing Bandwidth.

Signed urls would not, I think, be an option for mobile apps, which wouldn't be able to keep any secret information.

Should the client always go through a server under my control requesting the image by an internal id, rather than by the cloudinary url? The intermediary server would then request the image from cloudinary and serve it back to the client, so that the client never knows the cloudinary image url?

This approach doesn't seem ideal to me, as the user would need to wait for the image to be downloaded twice (once to the intermediary server and once to the client).

I guess I'm missing out some information... Could you please point me in the right direction?

Thanks.

 
 
1

Comments

6 comments

Date Votes
  • Ido
    Edited

    Hi

    Signed URLs allow generating images on the fly only if they are signed. So it prevents the situation generating images by users which are not approved.

    It's true that once the URL was generated and sent into the wild, its possible to use it over and over. This is true for any image link out there.

    We do support other access control methods such as token-based authentication which allows the delivery URL itself to be valid only under certain conditions that can be configured.

    Please note that this is available for our enterprise plans 

    You can read more about access control for images in the link below:

    https://cloudinary.com/documentation/image_transformations#control_access_to_images

    Please, let me know if you have any further questions.

    0
  • Flaviu Ratiu

    Thanks for the quick response. I went through the suggested documentation.

    My main concern was related to having some protection against this kind of abuse in native apps, which cannot keep any long term secret (I've updated the title to better reflect this).

    Would any of the supported access control methods be secure in native apps?

    Thank you.

     

     
    0
  • Marissa Masangcay

    Hi Flaviu,

    Auto-expiring signed URLs are generated from the server side so they are applicable to native apps as well (assuming the native app has a server side)

    We do also offer whitelisting based on user agent for our Enterprise plan if that is something that you would be interested in.

    Hope this helps.



    1
  • Flaviu Ratiu
    Edited

    Generating auto-expiring signed urls from the server side might work for me.

    Just one more question: does the Cloudinary API support generating auto-expiring signed URLs or how can they be generated? And is this available in the free plan?

    Thank you.

     
     
    0
  • Marissa Masangcay

    Hi Flaviu,

    Our Token-Based and Cookie-Based authentication are time-limited,  but they're both offered for the Enterprise plan as well.

    An option for the free plan would be to upload your images as type 'authenticated' and this will restrict access to both the original and derived versions of the image. The only way the public will be able to view the URLs is via signed URL authentication. 

    You can read more about our authenticated signed URLs here:
    https://cloudinary.com/documentation/image_transformations#signed_url_authentication

    Hope this helps!

    0
  • Flaviu Ratiu

    Thanks Marissa,

    The information you provided was really helpful.

     
    1

Post is closed for comments.

Didn't find what you were looking for?

New post