Safely sharing images behind a reverse proxy

[jordykoppen]

Hi, I want to open a discussion on safely exposing and sharing an immich instance to the public without opening myself up to potential attack vectors. Specifically, as there is little to find about this use case in combination with Pangolin. This discussion could serve as a resource for people wanting to achieve the same.

Some context:

• Immich running in an LXC container on Proxmox. Reachable on http://immich:2283.
• Proxmox resources exposed with a Pangolin newt instance, configured to accept clients (subnet router).
• External VPS setup, running Pangolin, proxying resources like immich back to my local server https://immich.DOMAIN.com

Now everything is working as expected, I can access Immich outside my home through the browser or iOS app by using the https://immich.DOMAIN.com. (on iOS, I have to set my server URL to https://immich.DOMAIN.com/api (why?)) with Pangolin's authentication layer infront.

But what is a self-hosted iCloud/Google Photos alternative without being able to share your images/albums easily with friends and family? To support this, I configured the following rules in Pangolin:

Priority	Action	Match Type	Value
1	Always Allow	Path	/share/*
2	Always Allow	Path	/_app/*
3	Always Allow	Path	/api/*
4	Always Allow	Path	/favicon.ico
5	Pass to Auth	Path	*

Now my question is, is it safe to expose these routes/paths publicly? Beforehand, I only exposed specific /api/ paths like /api/server/*, /api/shared-links/*, /api/assets/*. However, this resulted in iOS not being able to connect, whilst sharing links worked fine without authentication.

[mmomjian]

Everything important is under the /api endpoint. If you expose this entire path you might as well expose the whole site, there’s no difference.

[jordykoppen]

As in, no different from completely disabling auth on the pangolin side and fully relying on Immich's auth layer?

[mmomjian]

Yes, that's correct.

[bo0tzz]

Sounds like you might be looking for https://github.com/alangrainger/immich-public-proxy

[domnantas]

This solution is view-only. Uploads are not going to be added, because it requires exposing /api: https://www.reddit.com/r/selfhosted/s/SzXxPVhGcq

[Joloxx9]

Isn't better to create authentication token and use custom headers? You can keep pangolin SSO on, add pin etc and still have an access to the app, I did it, easy and good.

[Xeevis]

Exposing api/* is the FULL ACCESS, we can make exposed surface area smaller. I have used https://api.immich.app/endpoints as a reference and through try & error with pangolin singled out following endpoints. I didn't test extensively so it's still possible some functionality might be missing, but I think it's a good enough starting point and I've documented ones I've omitted just in case they might come in useful.

Endpoint	Description	Public sharing
/_app	JS/CSS assets	✅ NECESSARY
/s	Custom text sharing prefix	✅ NECESSARY
/share	Generated sharing prefix	✅ NECESSARY
/api/assets	Image or video that has been uploaded to Immich	✅ NECESSARY
/api/server	Information about the current server ⚠️ This one caused me headaches, when not present I got silent loop with memory leak that bricked browser and prevented it from fully closing, eventually taking 100% of PC RAM	✅ NECESSARY
/api/shared-links	Public url that provides access to a specific album, asset, or collection of assets	✅ NECESSARY
/api/albums	Assets that can be shared with other users or via shared links	🟢 USEFUL (Public upload)
/api/timeline	Specialized endpoints related to the timeline	🟢 USEFUL (Album view)
/api/download	Downloading assets or collections of assets	🟢 USEFUL (ZIP download)
/favicon-16.png	Wee little icon	🟢 USEFUL
/api/activities	Like or a comment made by a user on an asset or album	❌ NO
/api/admin	Administrative endpoints	❌ NO
/api/api-keys	Programmatically access the Immich API	❌ NO
/api/auth	User authentication	❌ NO
/api/oauth	User authentication	❌ NO
/api/duplicates	Managing and identifying duplicate assets	❌ NO
/api/faces	Human faces within assets	❌ NO
/api/jobs	Queues and background jobs	❌ NO
/api/map	Retrieving map markers for assets with geolocation data ⚠️ I still get map markers even without it	❌ NO
/api/memories	Specialized collection of assets with dedicated viewing implementations	❌ NO
/api/partners	Link with another user that allows sharing of assets between two users	❌ NO
/api/people	Collection of faces, which can be favorited and named	❌ NO
/api/notifications	Messages sent to users to inform them of important events	❌ NO
/api/libraries	Input file paths or expressions that are scanned for asset files	❌ NO
/api/users	Viewing and updating the current users	❌ NO
/api/system-metadata	View, modify, and validate the system metadata	❌ NO
/api/sync	New mobile synchronization implementation	❌ NO
/api/stacks	A grouping of related assets	❌ NO
/api/tags	Applied to assets for organization	❌ NO
/api/trash	Managing the trash can	❌ NO
/api/search	Searching assets via text, smart search, optical character recognition (OCR), and other filters	❌ NO
/api/queues	Used for processing tasks asynchronously	❌ NO
/api/plugins	Filters and actions available for the workflow feature	❌ NO
/api/system-config	View, modify, and validate the system configuration settings	❌ NO
/api/sessions	Authenticated login session for a user	❌ NO
/api/workflows	Set of actions that run whenever a triggering event occurs	❌ NO
/api/view	Specialized views, such as the folder view	❌ NO

[amnesiacsardine]

Thank you for sharing! Consider contributing it to Immich/Pangolin documentations.