0

"I'm playing audio file in my web application. If i inspect in the network i can able to get the exact file path of audio. Getting actual file path of audio leads to security problem. How to prevent this.

Vinodha
  • 9
  • 7

2 Answers2

-1

You can't. You can make this process difficult for the user but if your app in the browser can get any data from server then it can be done without your app too.

Dimanoid
  • 6,999
  • 4
  • 40
  • 55
  • Why would you give an answer without research? there are multiple ways to do it - and he just wanted to prevent the URL from being copy-pasted easily, check my answer for an example. – Liron Navon Jul 19 '19 at 08:13
  • As I said you can make this difficult but you cant protect the data on client side. – Dimanoid Jul 19 '19 at 08:55
-1

You cannot prevent the file path from appearing - but there are ways to prevent it from being used outside the application - or at least being used easily outside the application.

The steps are pretty much the same for any file (Blob) so it would be the same for an audio or video file.

You can prevent it by downloading the file with XHR and converting it to a blob URL - which is what Youtube and Netflix do for video - that way you have full control over the authentication and download process (make sure you download and merge each chunk with a range request to create a full video while streaming the information).

for example: for youtube this is a video URL - it is also revoked after a while so you probably can't open this file with your browser.

This URL is not protected - but there are protected video files on youtube for their premium services which will expect certain headers and cookies to be present. In order to make this fully protected, you would have to generate a onetime token for each chunk.

https://r6---sn-4g5ednll.googlevideo.com/videoplayback?expire=1563544755&ei=U3gxXZKKFoKZgQeOuYuoBA&ip=62.41.73.80&id=hHW1oY26kxQ.348&itag=140&source=yt_live_broadcast&requiressl=yes&mm=44%2C26&mn=sn-4g5ednll%2Csn-5hne6nsz&ms=lva%2Conr&mv=u&mvi=5&pl=24&live=1&hang=1&noclen=1&mime=audio%2Fmp4&gir=yes&compress=yes&mt=1563522739&fvip=4&keepalive=yes&c=WEB&sparams=expire%2Cei%2Cip%2Cid%2Citag%2Csource%2Crequiressl%2Clive%2Chang%2Cnoclen%2Cmime%2Cgir%2Ccompress&sig=ALgxI2wwRQIhANT3eXWZbPN0bFz5j7Zs56veNXpvNuXcvt0yOzwlNx-zAiB4ZjcCA7GTn6k16AiwQcOq2XaUkA3SWFuIdskws8MqBQ%3D%3D&lsparams=mm%2Cmn%2Cms%2Cmv%2Cmvi%2Cpl&lsig=AHylml4wRgIhAJ3FqpB1r_T_ErODyHxwcWZZdhxeVJ1yTdovfn0BPBmuAiEA5KbeCcZXe8C7l6W5IjmXWXwN1VXvgwiP7Jn2tWdReoc%3D&alr=yes&cpn=rp9-DtQeCOUxaQZ9&cver=2.20190718&sq=1134933&rn=10&rbuf=15966

Is transformed at runtime to this, and this URL is only local to the user session on the website and cannot be used to download manually unless they inject a script to the website.

blob:https://www.youtube.com/f49abcd9-d431-42f0-8e04-4e156a78a8cc

Now you need to make sure the video is only accessible by authenticating the user the normal way (HTTP only cookies - so users can't get it easily) + CSRF + CORS

  1. CORS - only accept requests with access-control-allow-origin: https://www.youtube.com
  2. JWT - only accept validated users (cookies)
  3. CSRF - token to prevent cross-site forgery (i.e users can't access it without going through the website) - they get invalidated after each user session.
  4. SSL - It is always a good idea to have SSL to prevent easy interception

This is more difficult than I make it sound, and smart hackers can still download the file with extra steps (there are downloaders for Youtube/Udemy/Netflix etc...) - but for the most part, it will prevent most users from easily downloading it.

** In case this isn't clear - there is no solution that involves only the client - the fix must come from the server-side to prevent access to the file.

Liron Navon
  • 1,068
  • 1
  • 11
  • 22
  • All the solutions I suggested are server-side. In order to protect it, you need to be able to control the way you download the file - that is where the blob URL comes in. as I said, you need to authenticate the user if you want this to be fully protected. And the CORS/CSRF part is for blocking the user from just using the URL as is - `get the exact file path of audio` as OP mentioned here. If the OP decided to authenticate the user or not is his decision - but you try to discourage him for no reason here - stop being toxic, and don't downvote in random with no justification. – Liron Navon Jul 19 '19 at 09:32