As designed All video attachments are publicly accessible

[Sim]

Affected version

2.3.4

It seems that all video attachments are stored in the data directory rather than in internal_data - which means that they are publicly accessible, even on a private forum, unlike photos or other attachments.

If someone was to extract the video URL from the page and send it to a 3rd party who does not have access to the forum, they would still be able to view the video.

Steps to reproduce:

1. in a forum that does not have public access, create a post with the following items attached:
   1. an image
   2. a document, such as a PDF file
   3. a video
2. copy the URLs for each of the three attached items above
3. in a browser that is not logged in to the site, try to access the three URLs
4. You should see the following results:
   1. the image cannot be viewed - you get an error message, as expected
   2. the document cannot be viewed - you get an error message, as expected
   3. the video can be viewed without any challenge to log in. This is unexpected behaviour.

This is pretty serious if I'm sharing private video content that can be arbitrarily viewed by 3rd parties or embedded in other sites.

Yes, I get that you'd need to know the URL of the video and if you can access that, then it's fairly trivial for a technically competent person to download the video or the image/document and share it - but it's still unexpected behaviour and sharing a link is quite different to downloading the content and then sharing the content itself.

Either way - why do we go to the trouble of protecting the images and documents if we aren't also protecting videos?

 

[Chris D]

This is, unfortunately, as designed.

It's not possible to stream video content from behind the Attachment controller. Many methods were attempted to workaround this, but for various reasons it was not technically feasible.

There's no current plans to change this.

 

[Sim]

This is, unfortunately, as designed.

It's not possible to stream video content from behind the Attachment controller. Many methods were attempted to workaround this, but for various reasons it was not technically feasible.

There's no current plans to change this.

I suspected this might be the case.

Looks like we'll need to build some kind of video hosting/streaming service integration to be able to host videos securely on our forums.

 

[Chris D]

Certainly open to suggestions on how to handle this differently in XF.

On a per-case basis, it might be easy to do with some additional web server configuration. Perhaps some sort of system of pre-signed, short-lived URLs. This is mostly what I meant by "technically feasible". There are probably approaches, but none that would "just work" without potentially heavy customisations which most customers can't make themselves.

 

[Moshe1010]

I suspected this might be the case.

Looks like we'll need to build some kind of video hosting/streaming service integration to be able to host videos securely on our forums.

We use Bunny.net and restrict it to our domain only. Users can’t watch any embedded video via the direct link. They get 403 error

 

[RobinHood]

Syntax.fm had an interesting episode on video streaming recently, you might find some interesting info or leads on platforms to integrate.

I believe they mentioned Bunny too.

Streaming Video in 2025 - Syntax #859

In this episode Wes and Scott discuss video streaming in 2025 - how HLS streaming works, transcoding and hosting video files, CDNs, player libraries like MediaChrome, and various video platform options.

syntax.fm

 

[Kirby]

It's not possible to stream video content from behind the Attachment controller.

I might be missing smth. (obvious), but:
Why isn't that possible?

IIRC I implemented video streaming in a custom controller and it seemed to work just fine (though I probably wouldn't use this in production, streaming large amounts of data through PHP is not terribly efficient)

 

[D.O.A.]

I have a add-on that runs video attachments through nginx secure_links, I can share that here probably. Direct video links will not work, they'll 404. Must have the time limited token.

 

[pegasus]

Yup, it's completely doable, just a lot of work. I also implemented video streaming in a custom controller and custom player Javascript for one of my sites. In the backend, you need ffmpeg to generate dash fragments and hls fragments, bandwidth versions, etc, and then you need some knowledge of these formats to put them together as they are requested. It can be inefficient (massive bandwidth cost) if the video file data is hosted on a different network/interface from PHP, so it should probably be forced onto the same box. Video transcoding also needs to be queued and tuned to avoid DDOS from simultaneous uploads. You also want to log bandwidth usage in general, because even dedicated servers can limit you to a certain number of TB. In my player, after various threshholds are reached, streaming services automatically throttle by serving lower bandwidths as the usage increases.

 

[zoldos]

So only attached videos have this "vulnerability"? Videos uploaded to the gallery and any video attached in a thread?

I recall that any item in the MG could be shared via a direct link that anyone on the web could then access. I even removed that particular code from MG.....