Hubspot Serverless Functions untrusted context parameters

Develop, Build & Integrate App Development
1

The problem
When an app card calls an app function, HubSpot sets portalId and user on the server, so the function can trust who is calling. The record the card is displayed on gets no such guarantee. Its ID only reaches the function through parameters or propertiesToSend, in a request built by the browser, and HubSpot Support confirmed that the user’s access to that record isn’t checked.

So any function that returns data about the current record (an embedded report, a document, data from another system) has to rebuild record-level authorization itself. Otherwise a user can replay the call with another record’s ID and get data about a record they can’t open in HubSpot.

Why now
Legacy CRM cards received associatedObjectId in a request signed by HubSpot. They are deprecated on November 2, 2026, and app cards with app functions have no equivalent. Migrating removes a guarantee that apps relied on.

Proposal (any one of these would solve it)

  1. Add the record to the server-set context (for example context.crm.objectId and objectTypeId), set only when the calling user can view that record.
  2. Resolve propertiesToSend with the calling user’s permissions, and reject the call when they can’t view the record.
  3. For hubspot.fetch, append the record ID resolved by HubSpot to the signed query parameters, next to userId and portalId.

Why it matters
HubSpot already knows which records each user can view. Enforcing that in the platform would make the common “card shows data about this record” pattern safe by default, instead of every app rebuilding it with the permitted-users API or its own ownership rules.

This was also filed as a feature request through HubSpot Support. If you build app cards that call a backend, an upvote helps.

3

Hi @FCarneiro :hugs: and welcome back to the HubSpot Community! Delighted to see you again here!

Thanks for taking the time to share this feature request and the possible solutions with us!

It’s great that you’ve already submitted this through HubSpot Support. I’d also encourage you to share it via the HubSpot Developer Feedback Form so that the right team can have their eyes on it.

Thanks so much and have a lovely day!

Bérangère, HubSpot Community Manager

- For information, I’ll be out of the office from the 26th to the 30th of October included -

5

I think option 1 is the best approach in this scenario. Ideally, Hubspot should automatically provide the record ID and record type to the backend but only after confirming that the user has permission to view that record. Checking the permissions every time the function is called is also a good practice I think, not just when the card loads. If no access, then reject the request. This would create better security without requiring every developer to build their own permission checks.