When a client opens their dashboard on a HubSpot portal, the page asks the back end for something like “requests for client 123.” Something has to check that the person asking is client 123. If the code trusts the number the browser sends, any client can read any other client’s requests by changing it.
That one check is where a portal’s security actually lives, and on HubSpot it isn’t the platform’s job. It’s whoever wrote the code.
Is a private page on HubSpot secure?
A private page decides who may open it. That’s all “private” means. It doesn’t encrypt anything, and HubSpot says so of pages behind a shared password: they aren’t indexed, “but sensitive data isn’t encrypted.” Member logins are stronger, because each person has their own sign-in. But once a member is signed in, keeping their records away from every other member is the portal’s own logic, written by your builder.
That kind of flaw is the most common one on the web. OWASP’s 2025 Top 10 puts broken access control first, and every application in its testing data had some form of it, including “viewing or editing someone else’s account by providing its unique identifier.” 1 Source 1 OWASP Top 10:2025, “A01 Broken Access Control,” read October 30, 2026: the category holds “its position at #1 in the Top Ten”; “100% of the applications tested were found to have some form of broken access control”; it includes “permitting viewing or editing someone else’s account by providing its unique identifier (insecure direct object references).” Nothing about HubSpot makes it more likely. Nothing about HubSpot prevents it either.
The platform carries risk of its own, too. On October 28, 2026, HubSpot disclosed a flaw it classified as critical: a template-injection bug in a CMS preview endpoint through which, under certain conditions, someone who wasn’t signed in could have retrieved CRM data. HubSpot had it blocked within hours of the October 13 report and a permanent fix live that morning, and it reports no evidence the flaw was exploited. 2 Source 2 HubSpot Trust Center, “HubSpot CMS SSTI Vulnerability Resolved,” posted October 28, 2026: “a Server-Side Template Injection (SSTI) vulnerability in a CMS preview endpoint on HubSpot-hosted domains”; “We classified this issue as a critical finding”; under certain conditions “an unauthenticated party could have used this issue” to “retrieve CRM data associated with a HubSpot account”; report received October 13 at 2:17 AM EDT, a firewall rule in place by 7:44 AM and the permanent fix deployed by 10:35 AM; “we have no evidence that this issue was exploited.” That’s a fast, open response. It’s also a reminder that when a portal’s client records live in the CRM behind your marketing site, a flaw in the marketing site can be a route to them.
So the useful question isn’t whether HubSpot is secure. It’s whether your portal is, and that takes twelve more specific questions. You don’t need to read code to ask them. You need someone who can answer each one plainly.
Who can get in?
1. How does a client get access, and who removes it when they leave?
On HubSpot, access to private content comes from access groups. A static group holds contacts someone added by hand or from a static segment; a dynamic group adds contacts automatically from filters. 3 Source 3 HubSpot Knowledge Base, “Create and manage access groups for private content,” updated September 29, 2026: “Password-protected content isn’t indexed by search engines, but sensitive data isn’t encrypted”; access groups are static (contacts added manually or through static segments) or dynamic (added automatically based on filters); up to two access groups on Professional and 100 on Enterprise. A good answer names the rule that grants access, the event that removes it (a client relationship ending, an employee of a client leaving), and who checks that it happened.
2. What happens when someone walks away from a signed-in screen?
Idle sign-out is a checkbox someone has to turn on, per domain, with a timeout from 15 minutes to 24 hours. 4 Source 4 HubSpot Knowledge Base, “Manage settings for private content,” updated December 12, 2025: turn on the “Automatically sign out inactive users” checkbox to sign users out after 15 minutes up to 24 hours of inactivity, set individually for each connected domain. If the portal shows financial, medical or legal information, the answer should be a number someone chose on purpose.
What can each person see?
3. When a client asks for a record, does the code check it belongs to them?
This is the client-123 question, and it’s the one that matters most. On HubSpot’s CMS, a function can ask whether the visitor is a logged-in member through context.contact, which HubSpot fills in only when the request comes from a recognized contact. 5 Source 5 HubSpot Developers, “Serverless functions reference” (CMS), read October 30, 2026: context.contact.isLoggedIn is true when the contact is logged in, and the contact object is populated only if the request comes from a cookied contact; 50 secrets per account. Developer platform “Serverless functions reference”: the endpoint config “defines a publicly accessible endpoint (without authentication)”; “Consider implementing your own authentication logic (API keys, tokens, etc.)”. Here’s the good answer. Every request is checked against the signed-in identity on the server, never against an ID the browser sends, and there’s a test that tries to read someone else’s record and fails.
4. Are any of the portal’s endpoints public?
On HubSpot’s newer developer platform, a function’s public endpoint is, in HubSpot’s words, “a publicly accessible endpoint (without authentication),” and the docs suggest “implementing your own authentication logic.” Ask for the list of every endpoint the portal exposes, and what protects each one.
5. Is anything sensitive sitting behind a shared password?
A page behind one password everyone shares has no idea who is looking at it. Ask whether any client documents, statements or personal details are on pages like that, or in a HubDB table someone set to allow public API access, which we cover in the data piece.
Every request is checked against the signed-in identity on the server, never against an ID the browser sends…
What can the portal’s code reach?
6. Which access keys does the portal use, and what can each one do?
A portal’s back end usually talks to the CRM with a private app token, and each token carries the scopes chosen when the app was set up. Only Super Admins can see private apps, an account can have up to 20, and HubSpot recommends rotating each token every six months. 6 Source 6 HubSpot Developers, “Legacy private apps,” read October 31, 2026: “You must be a super admin to access private apps in your HubSpot account”; up to 20 private apps per account; HubSpot recommends rotating a token every six months, with “Rotate and expire now” for a compromised token; if the user who created a private app is removed, some calls fail with USER_DOES_NOT_HAVE_PERMISSIONS until the token is rotated. A good answer lists each key, what it can read and write, and when it was last rotated. “It has access to everything” is an answer, but not a good one.
7. If a key leaked tomorrow, what would it expose, and how fast could you shut it off?
HubSpot lets a Super Admin rotate a token and expire the old one immediately. The question is whether anyone would know to, and how many integrations would break when they did. Ask for the plan, not the button.
Who can change the portal?
8. Who in your HubSpot account can edit the code the portal runs on?
Any user with HubSpot’s Design tools permission can edit templates and modules, and Super Admins “can do virtually anything in the account.” 7 Source 7 HubSpot Knowledge Base, “HubSpot user permissions guide,” last updated October 29, 2026: the Design tools permission lets a user “edit templates and modules”; “Super Admin can do virtually anything in the account.” HubSpot Knowledge Base, “View and export account activity history,” last updated October 30, 2026: “Super Admin permissions are required to view and export audit logs”; views cover the last 30 days; Content, Workflows and other categories are Enterprise-only; “Updates to properties not made by a user (e.g., a form submission) won’t display in the audit log.” In some accounts that’s a marketing team, an agency or two and a former contractor. The good answer is a short list, reviewed on a schedule.
9. Is every change reviewed by a second person and recorded?
Ask what changed last Tuesday, who changed it and who approved it. If the answer means searching an editor’s history or asking someone who has since left, changes aren’t being controlled. We explain why it’s hard on HubSpot in Does HubSpot Have a Sandbox? Not One That Copies Your Portal.
What record is kept?
10. Is there a record of who viewed or changed each client’s records through the portal?
Not unless the portal keeps one. HubSpot’s audit log is for Super Admins, covers 30 days, and records actions by HubSpot users. HubSpot notes that updates “not made by a user (e.g., a form submission) won’t display in the audit log.” Your portal’s members are contacts, not HubSpot users. If an auditor or a client asks who saw a document, the answer has to come from logs the portal writes itself.
11. If clients and staff message each other through the portal, is that kept the way your regulator expects?
Recordkeeping rules don’t stop at email. To take one example, the SEC’s books and records rule for investment advisers covers “originals of all written communications received and copies of all written communications sent” on the subjects it lists, and requires them to be kept for at least five years, the first two in an appropriate office. 8 Source 8 17 CFR 275.204-2 (SEC books and records rule for investment advisers), via Cornell Law School’s Legal Information Institute, read October 31, 2026: paragraph (a)(7) covers “originals of all written communications received and copies of all written communications sent” on listed subjects, including advice given; paragraph (e)(1) requires records be kept “for a period of not less than five years,” the first two “in an appropriate office of the investment adviser.” Healthcare and law have rules of their own. HubSpot doesn’t archive messages exchanged through a custom portal on your behalf, so the good answer describes the archive, the retention period and how a message is found again on request.
12. If you left HubSpot, could you take the portal’s records and their history with you?
Records export object by object. The relationships between them, and the history of who did what, are what make them useful. Ask how that history would come out, and in what shape. Our piece on where a portal’s records live walks through why the answer matters.
The twelve questions, in one place
Copy these into an email to whoever built or maintains your portal:
- How does a client get access, and who removes it when they leave?
- Is idle sign-out on, and at what interval?
- When a client asks for a record, does the code check it belongs to them, using the signed-in identity rather than an ID from the browser?
- Which of the portal’s endpoints are public, and what protects each one?
- Is anything sensitive behind a shared password, or in a table that allows public access?
- Which access keys does the portal use, what can each one read and write, and when was each last rotated?
- If a key leaked, what would it expose, and what’s the plan for shutting it off?
- Who can edit the templates and functions the portal runs on?
- Is every change reviewed by a second person and recorded?
- Is there a log of who viewed or changed each client’s records through the portal?
- Is client correspondence through the portal archived the way our regulator expects?
- Could we take the portal’s records, and their history, with us if we left?
A portal that’s ready for clients has a clear, specific answer to every one. If several come back as “we’d have to check,” that’s your list of what to fix first, in roughly that order.
What a portal you can prove gives you
The goal isn’t a scare. It’s a portal your compliance lead can sign off and your auditors can inspect: access that matches the client list, every record checked against the person asking, keys that can only do what they need to, changes that are reviewed and recorded, and a trail of who saw what that you own.
That’s what lets a firm move more of its client relationship into the portal with confidence. Security you can describe is also security you can explain to a client who asks.
On HubSpot, most of these answers depend on how the portal was built rather than on the platform, which is why the questions matter more than the logo on the account. The wider trade-offs are in Can You Build a Customer Portal on HubSpot?, and sign-in specifically in HubSpot Memberships: What Your Clients See, and What You Can’t Change. Public endpoints are part of HubSpot Serverless Function Limits for Client Portals (2026). Our other piece on platform security, about a very different platform, is WordPress’s security debt.
The research is free. So is the diagnosis. 60 seconds →