Immich Public Proxy: Safely share your photos and albums without exposing your Immich instance
from alan@feddit.org to selfhosted@lemmy.world on 11 Nov 12:30
https://feddit.org/post/4639027

Immich is an amazing piece of software, but because it holds such personal data I have only ever felt comfortable accessing it via VPN or mTLS. This meant that I could never share any photos, which had been really bugging me.

So I built a self-hosted app, Immich Public Proxy, which allows you to share individual files or full galleries to the public without ever exposing your Immich instance. This uses Immich’s existing sharing functionality, so other than the initial configuration everything else is handled within Immich.

Why not just expose Immich publicly with Traefik / Caddy / etc?

To share from Immich, you need to allow public access to your /api/ path, which opens you up to potential vulnerabilities. It’s up to you whether you are comfortable with that in your threat model.

This proxy provides a barrier of security between the public and Immich. It doesn’t forward traffic to Immich, it validates incoming requests and responds only to valid requests without needing privileged access to Immich.

Demo

You can see a live demo here, which is serving a gallery straight out of my own Immich instance.

Features

Install

Setup takes about 30 seconds:

  1. Take a copy of the docker-compose.yml file and change the address for your Immich instance.

  2. Start the container: docker-compose up -d

  3. Set the “External domain” in your Immich Server Settings to be whatever domain you use to publicly serve Immich Public Proxy. Now whenever you share an image or gallery through Immich, it will automatically create the correct public path for you.

For more detail on the steps, see the docs on Github.

#selfhosted

threaded - newest

BaroqueInMind@lemmy.one on 11 Nov 12:51 next collapse

This is excellent! Thank you!

just_another_person@lemmy.world on 11 Nov 13:34 next collapse

Okay…I’m terribly confused by this project here, so maybe you can clarify some things.

First, looking through the code, it seems you’re literally just taking input requests and replaying them to a target host. So if Immich is updated with changes that proxy doesn’t have yet, everything breaks.

How is this adding more security than any other proxy?

alan@feddit.org on 11 Nov 13:42 collapse

You’re correct - it is indeed taking input requests and requesting the related data from Immich.

How is this adding more security than any other proxy?

To allow sharing with Immich using a normal reverse proxy like Caddy or Traefik, you need to expose public access to the Immich /api/ path, along with a few other potentially dangerous paths. Any existing or future vulnerability has the potential to compromise your Immich instance.

This proxy is more secure as it does not allow public access to the Immich API path or to any Immich path. The only incoming requests which are honoured are requests like this:

https://your-proxy-url.com/share/ffSw63qnIYMtpmg0RNvOui0Dpio7BbxsObjvH8YZaobIjIAzl5n7zTX5d6EDHdOYEvo

If the shared link does not resolve to something that you have intentionally shared from Immich, it will return a 404.

if Immich is updated with changes that proxy doesn’t have yet, everything breaks.

The only thing which would break it is if Immich changed the format of a few select API endpoints. And if that ever happens it’s a very easy fix.

just_another_person@lemmy.world on 11 Nov 13:47 collapse

Or you could similar just block those routes in whatever reverse proxy you’d use out in front of the server?

I don’t run Immich myself, but just trying to understand the technical issues and this particular solution. Seems like they should have a public facing /shared route that doesn’t require access to any others, so I see your point.

alan@feddit.org on 11 Nov 13:48 collapse

Or you could similar just block those routes in whatever reverse proxy you’d use out in front of the server?

You can’t. You need to allow public access to your Immich instance’s /api/ path to use Immich’s built-in sharing.

atzanteol@sh.itjust.works on 11 Nov 13:42 next collapse

You seem to understand neither security nor privacy.

I get to give you access to all my photos so that you can just proxy calls to my server?

Just share your own damn server people, this “I’m behind 7 proxies” bs is getting tiring.

alan@feddit.org on 11 Nov 13:49 next collapse

I get to give you access to all my photos so that you can just proxy calls to my server?

This is a self-hosted app… The only person who has access to your photos is you - that’s the entire point of using this. It lets you share photos/videos/albums from Immich without giving anyone access to any part of your Immich server, thus significantly increasing your privacy and security.

It doesn’t forward any traffic to Immich, it creates essentially a WAF between the public and Immich. It validates all incoming requests and answers only valid requests, without needing privileged access to Immich.

Appoxo@lemmy.dbzer0.com on 11 Nov 20:12 collapse

Couldnt this in theory also be handled by using cloudflares WAF and disallowing every entry to protected end-points?

alan@feddit.org on 11 Nov 20:29 collapse

You’d still need to allow access to the /api/ path, and even public endpoints could potentially expose you to a vulnerability. It’s entirely up to your threat model.

Knowing what happened in 2014 with iCloud, I’m not prepared to take that risk. Especially as Immich is under heavy development and things can often change and move around. At least this way I know that it will either safely fetch the data or simply fail.

cron@feddit.org on 11 Nov 13:50 next collapse

You‘re supposed to host this yourself.

[deleted] on 11 Nov 14:00 collapse

.

alan@feddit.org on 11 Nov 14:04 next collapse

I’m “exposing” my own server either way!

Put it on a different server then. It prevents your Immich server from ever needing to be exposed publicly. That’s the entire point.

This is stupid.

You seem to understand neither security nor privacy.

atzanteol@sh.itjust.works on 11 Nov 14:13 collapse

Put it on a different server then. It prevents your Immich server from ever needing to be exposed publicly. That’s the entire point.

This is stupid.

Repeat after me - proxies are not used for security.

This is a cargo-cult believe in this community. There’s a weird sense that it’s “dirty” to have a server exposed “directly” to the internet. But if I put it behind something else that forwards traffic to the server then that’s somehow safe!

Security is something you do not something you have. The false sense of security with proxy bullshit like this crappy project is not giving you anything. You’re taking a well supported community project (immich) and installing another app in front of it which appears to be some dude’s personal project and telling me that is more secure. As though that project is better written?

Install immich. Forward ports to it (or proxy it with nginx if needed for hostname routing (but don’t expect this to be more secure)), and keep it up to date and use good passwords.

alan@feddit.org on 11 Nov 14:20 next collapse

some dude’s personal project

Yes, it’s my project.

if I put it behind something else that forwards traffic to the server then that’s somehow safe!

It doesn’t “forward traffic”, it validates traffic and answers only valid requests, without needing privileged access to Immich. I think you are confusing the word “proxy” with meaning something like Traefik.

telling me that is more secure. As though that project is better written?

Yes, it’s more secure to use this than exposing Immich. No it’s not “better written” than Immich; it fulfills a completely different purpose.

It’s 400 lines of code in total, feel free to review it and tell me any flaws, oh mighty security expert.

[deleted] on 11 Nov 15:28 collapse

.

azron@lemmy.ml on 11 Nov 17:08 collapse

Hahah. You must be bored.

atzanteol@sh.itjust.works on 12 Nov 04:25 collapse

Kinda - It’s the only reason I bothered to reply to anyone. :-)

doeknius_gloek@discuss.tchncs.de on 11 Nov 14:38 next collapse

Security is something you do

Like by reducing the attack surface on internal APIs?

I don’t even necessarily disagree with you, everybody has to decide themselves if this app offers enough upsides to be worth the downsides.

That being said, instantly calling OP stupid and their project crappy is just not the way to get your point across and in general considered a dick move.

atzanteol@sh.itjust.works on 11 Nov 14:51 next collapse

Like by reducing the attack surface on internal APIs?

This is my other favorite term the community has picked up and uses like it’s a mic drop without understanding it.

It’s a proxy my friend. It forwards requests to the other server. And you’ve added an untested personal project in front of it.

But wait! You don’t want to just expose your immich proxy to the internet do you? I’ll write DavesAwesomeProxy that you can put in front of that proxy! Will it be secure? Maybe. Will I support it? What’s with all the questions!

alan@feddit.org on 11 Nov 14:54 collapse

It forwards requests to the other server.

No raw requests are passed to Immich. All incoming data is validated / sanitized. Requests are only made to specific whitelisted API endpoints. I don’t know why you’re so angry 🤷

[deleted] on 11 Nov 14:52 collapse

.

betweenthesixes@lemm.ee on 11 Nov 14:56 collapse

Repeat after me - proxies are not used for security.

If you believe this, you are extremely uninformed at best. Proxies are routinely used for security in situations like this and are used to secure many of the apps that you use on the public internet today.

Thank you OP for creating this app! Please ignore any negativity from ignorant detractors.

atzanteol@sh.itjust.works on 11 Nov 15:24 collapse

Proxies are not used for security by anyone but morons. Firewalls, WAFs, etc. all provide some sort of benefit. What is this application doing that is of use? Just “not exposing your server directly”? Well, it is being exposed directly now - so it’s a very secure application written by a security professional then? Or should I put it behind another proxy just to be sure? Maybe 7 proxies are enough?

OP is well meaning - but this was a waste of time for anyone else to use. It’s a solution in search of a problem.

ShortN0te@lemmy.ml on 11 Nov 15:36 collapse

You have clearly not understood what it does. It basically acts as a basic WAF by blocking the access to various paths that are required by the default sharing feature but not by this “proxy”.

thelittleblackbird@lemmy.world on 11 Nov 14:15 next collapse

This thing reduces the attack surface of the inmich installation.

If it is good, or bad or fitting to your security model can only be said by you. But honestly it sounds like a sensible thing to do

atzanteol@sh.itjust.works on 11 Nov 15:36 collapse

And it adds its own “attack surface”.

Lemongrab@lemmy.one on 11 Nov 16:02 collapse

And? It lowers the attack surface of Immich. Attack surface is about the surface, whatever an attacker can use to get leverage. This acts as an intermediate between Immich and a public viewer, controlling how a threat actor can access a private Immich server. It helps reduce external attack surface while increasing overall system complexity. Since the project is small, it is easy to audit the code.

atzanteol@sh.itjust.works on 12 Nov 04:28 collapse

It’s some rando’s project that has existed for “nearly a month”, has no community, is unlikely to have any rapid response to any issues, and probably won’t be supported for more than a year.

But sure - go ahead and run it for “security purposes”.

You can “reduce surface area” by simply putting in place nginx or apache (real supported software) and blacklisting the endpoints you don’t like.

Lemongrab@lemmy.one on 12 Nov 07:26 collapse

I like to judge software based on its actually merit and not on the theoretical possibility it is vulnerable. It very well could be vulnerable, but without auditing it we are just speculating, which in the real world means nothing. Every project starts somewhere, without community, followers, and “5 years of support”. I am not saying I would trust this software in a security critical situation, just that your speculation means nothing.

atzanteol@sh.itjust.works on 12 Nov 15:37 collapse

I like to judge software based on its actually merit and not on the theoretical possibility it is vulnerable

This is literally the entire justification for the project. It’s assuming theoretical vulnerabilities in Immich.

I am not saying I would trust this software in a security critical situation

Which is the point of this software (security critical situation).

just that your speculation means nothing

This project has zero community support. That’s not speculative, it’s a fact. “Every project starts somewhere” is just a tautology that means nothing. Every project that fails starts somewhere.

alan@feddit.org on 12 Nov 18:28 collapse

It’s assuming theoretical vulnerabilities in Immich.

It’s all about the risk matrix. The theoretical likelihood of a vulnerability in Immich might be low, but the severity of that risk is catastrophic in terms of personal data leaking.

The likelihood of a risk in this proxy might be medium or even high according to you, but the severity is low. It doesn’t have access to any of your personal data. All it does is talk to Immich via Immich’s public sharing API.

This project has zero community support.

One of the contributors to this project is bo0tzz, who is one of the maintainers of Immich.

atzanteol@sh.itjust.works on 12 Nov 20:54 collapse

The likelihood of a risk in this proxy might be medium or even high according to you

It might be zero. It’s “unknown” (according to me I guess).

I’ve dug into the code a bit out of curiosity - it seems to me that “proxy” is a misnomer. It’s a stripped-down “view” layer built on top of the API. But has the same endpoints as the main immich app for shared things so that you can create links that work with it so it kinda looks like a proxy. But it’s just a “simplified public view” of sorts.

Meh.

Wrongdoer4094@lemmy.world on 11 Nov 17:21 next collapse

I rarely post, but… Chill, man!

MangoPenguin@lemmy.blahaj.zone on 11 Nov 18:59 collapse

Why so angry?

This lets you share photos without directly exposing Immich to the internet.

I don’t see the point in getting so worked up over someones project they made and decided to share, it’s not like you’re being forced to use it.

[deleted] on 12 Nov 04:22 collapse

.

lemmeBe@sh.itjust.works on 12 Nov 03:40 collapse

For anyone else reading this completely unjustified and ill-intentioned criticism of the OP’s work: atzanteol obviously has no clue about security and therefore cannot comprehend the value of this library.

atzanteol@sh.itjust.works on 12 Nov 04:30 collapse

Do you often recommend people running single-developer maintained software that has existed for about a fortnight for “security purposes”?

Tippon@lemmy.dbzer0.com on 11 Nov 14:07 next collapse

You can see [a live demo here](https://immich-demo.note.sx/share/ffSw63qnIYMtpmg0RNvOui0Dpio7BbxsObjvH8YZaobIjIAzl5n7zTX5d6EDHdOYEvo), which is serving a gallery straight out of my own Immich instance.

Sorry, off topic, but is this what Immich looks like out of the box, or have you used any other plugins?

Immich Public Proxy looks like exactly what I want for my family photos, but I haven’t looked into Immich yet. The demo looks beautiful, and is simple enough for the grandparents to use 🙂

alan@feddit.org on 11 Nov 14:11 next collapse

Sorry, off topic, but is this what Immich looks like out of the box, or have you used any other plugins?

No - this is using lightGallery. You can see what Immich looks like on their demo.

Tippon@lemmy.dbzer0.com on 11 Nov 14:52 collapse

Thank you 🙂

Immich on its own looks good, but if I set it up, I think I’ll definitely install lightGallery to go with it 🙂

muntedcrocodile@lemm.ee on 11 Nov 16:31 collapse

Not default but can highly reccommend immich its great.

Tippon@lemmy.dbzer0.com on 11 Nov 19:40 collapse

Thanks 🙂

fmstrat@lemmy.nowsci.com on 11 Nov 14:20 next collapse

Oh man, total flashback to when I did this for Owncloud github.com/Fmstrat/shorten

lemmeBe@sh.itjust.works on 11 Nov 16:25 next collapse

Great work! 😎 Starred.

Appoxo@lemmy.dbzer0.com on 11 Nov 20:13 next collapse

Thank you very much for the work. I pondered a few times how I could do that safely as I don’t feel like hosting it that publicly.
I run Jellyfin publicly behind Authelia but there arent any personal files inside so if they breach it, it would give them only movies, music and tv shows…

markstos@lemmy.world on 11 Nov 21:18 next collapse

A simpler way to protect a private service with a reverse proxy is to only forward HTTP GET requests and only for specific paths.

It’s extremely difficult to attack a service with only GET requests.

The security of which URLS are accessible without authentication would be up to immich.

elvith@feddit.org on 11 Nov 21:45 next collapse

I don’t know the Immich API, but I’ve seen several REST APIs that used the usual pattern of

GET /api/v1/user/<id> - read user
POST /api/v1/user/ - create user
...

but also allowed

GET /api/v1/user/<id> - read user
GET /api/v1/user/?action=create - create user
...
davad@lemmy.world on 11 Nov 23:40 next collapse

Yup, also some APIs use GET for everything. It’s a pain. And it means that filtering by verb only helps if you’re intimately familiar with the API. And even then, only if you keep up with changes as they happen. So really, only if you’re developing the API yourself.

davad@lemmy.world on 11 Nov 23:41 collapse

(another pet peeve of mine is “rest” APIs that use 200 response codes for everything)

Atemu@lemmy.ml on 12 Nov 05:11 collapse

Ahhhhh whyyyyy, you’ve got all of these standard response codes made for you, why would you blatantly ignore them like that?!

davad@lemmy.world on 12 Nov 19:57 collapse

The only one I think is reasonable is GraphQL. But that isn’t rest, and HTTP is just one of the transport layers it supports.

For anything claiming to be RESTful, it’s a crime.

markstos@lemmy.world on 12 Nov 10:55 collapse

Yes, there are broken uses of the HTTP protocol verbs where filtering to GET won’t work.

alan@feddit.org on 12 Nov 07:46 next collapse

The security of which URLS are accessible without authentication would be up to immich.

This is exactly the risk I’m wanting to mitigate. Immich is under heavy active development, and I want to abstract away from needing to worry whether the no-auth API URLs are safe to expose publicly.

At the end of the day I feel safer knowing that there is zero public access to any part of my Immich instance, which for me is what really matters.

markstos@lemmy.world on 12 Nov 11:10 collapse

Immich has a whole set of end-to-end automated tests to ensure they don’t accidentally make public any URLs they went to be private:

github.com/immich-app/immich/tree/main/…/specs

As a popular open source project, that would be e glaring security hole.

Using this proxy puts the trust in a far less popular project with fewer eyeballs on it, and introduces new risks that the author’s Github account is hacked or there’s vulnerability in he supply chain of this docker container.

It’s also not true that you “never need to touch it again” . It’s based on Node whose security update expire every two years. New image should be built at least every two years to keep to update with the latest Node security updates, which have often been in their HTTP/HTTPS protocol implementations, so they affect a range of Node apps directly exposed to the internet.

alan@feddit.org on 12 Nov 15:04 collapse

All good points, and Apple has some of the most skilled engineers in the world and The Fappening still happened.

It’s not possible for me to audit everything that’s happening security-wise in Immich, but I can fully understand what’s happening in this small codebase to my own satisfaction. At the end of the day I feel safer knowing that there is no public access to any part of my Immich instance.

It’s also not true that you “never need to touch it again”

I meant that you don’t need to use it to share photos, not that you never need to update your docker containers! 😱 Thanks, I have clarified that.

numanair@lemmy.ml on 12 Nov 14:42 collapse

Interestingly the recent D-Link NAS security flaw uses GET.

markstos@lemmy.world on 13 Nov 23:49 collapse

Good example. It’s true that an even a GET request not designed to mutate data might still fail to validate input, allowing a SQL injection attack or other attack that escalates to the privileges that the running app has.

poszod@lemmy.world on 11 Nov 22:58 next collapse

Please Proton team port over this UI to drive.

warmaster@lemmy.world on 12 Nov 02:53 collapse

Material 3?

poszod@lemmy.world on 13 Nov 16:36 collapse

A lot more than that, especially the UX part.

Atemu@lemmy.ml on 12 Nov 05:18 collapse

Pretty cool!

Have you thought about whether this could also be used for limited write access? A common use-case for abusive image gallery services that you cannot ordinarily fulfil with Immich is shared albums where multiple people that e.g. attended the same event can collect pictures in without complex authentication (just a single shared secret or even just the link to the album).

Randelung@lemmy.world on 12 Nov 16:25 collapse

I’d love that, too. Immich has more fine grained user control on their timeline, though.