How to connect the UniFi Access API to the UniFi Make module without security concerns? 🔐

Questions
, ,
1

I’m working on a project where I need to connect a website + automation flows in Make with a UniFi Access setup for membership and access control automation.

The goal is to trigger actions such as:

:white_check_mark: Create/update users
:white_check_mark: Assign or revoke PIN codes
:white_check_mark: Block access on failed payments
:white_check_mark: Re-enable access after subscription renewal
:white_check_mark: Sync physical access with memberships

My concern is security.

I’d prefer avoiding classic port forwarding directly to the UniFi controller. I’m considering alternatives like:

• VPS bridge
• IPSec VPN tunnel
• Reverse SSH tunnel
• Cloudflare Tunnel
• Other secure architectures

For those who already integrated UniFi Access with Make:

How are you securely exposing the API while keeping automation reliable?

Curious to see what architecture the community recommends.

4

I’m the original author, but I’m not the developer anymore. Make has adopted the app and is maintaining it themselves now.

If you do connect straight to your Unifi Access API, then I definitely recommend setting your firewall settings to only allow communication via the whitelisted Make servers documented in the connection settings and only exposing the permissions you actually need when you create your API key in the Unifi Access dashboard.

There’s nothing stopping you from using a tunnel like Cloudflare. Defense in depth is a good idea if you’re a larger organization. It would get you some better logging and DDoS protection. But at the end of the day, an exposed API key is an exposed API key. If an attacker gets your API key, they’d still have to spoof the Make address (assuming you set up your firewall as recommended), but they could spoof that address just as easily on your tunnel endpoint as they could on the server itself.

I’ve also made the Unifi Access node for n8n, and my n8n node is more secure than the Make app specifically when it comes to triggers. Make only has the one “Door Open” trigger, and it doesn’t verify signatures like the n8n triggers do (I’m not sure there’s any way to get Make to do that). This would help prevent a man-in-the-middle from getting notifications about your door open events. But it doesn’t sound like you’re planning to use that feature anyway.

Also consider your risk profile. If the whole point of your integration is to allow people to buy access to your building, then attackers already have unfettered access to your building, they just have to throw a little money at it, and if that’s your business, then that attack vector is just something you have to accept.