A control that determines whether portal data is private or publicly reachable. In low-code portal systems, table permissions should limit which users can read, write, or delete records. When disabled or misapplied, the portal may expose data beyond the intended audience, especially when paired with API access.
Expanded Definition
Table permissions are the access rules that decide which users or roles can read, create, update, or delete records in a portal-backed table. In low-code portal platforms, they act as a record-level gate above the underlying data store, shaping whether information is private, scoped to a specific audience, or effectively exposed through the portal experience.
The boundary matters. Table permissions are not the same as the database’s native permissions, and they are not a substitute for application-side authorization logic. A table may be protected at the storage layer yet still exposed through a portal if the portal permission model is too broad. The reverse is also true: restrictive table permissions may make data appear unavailable even when the backend is reachable by other paths.
For practitioners, the common misunderstanding is treating portal permissions as a cosmetic configuration instead of an enforcement control. In practice, they govern whether the portal behaves like a controlled publishing layer or a data disclosure surface. The OWASP Non-Human Identity Top 10 is useful background where portal access is driven by service accounts, API keys, or other non-human access paths that can widen exposure if they are not scoped carefully.
Examples and Use Cases
- A citizen service portal allows authenticated users to view only their own submitted cases, using table permissions tied to ownership or membership.
- A partner portal exposes selected account records to external organisations, while keeping internal notes and operational fields hidden.
- A support workflow lets approved staff update ticket records but prevents them from deleting audit-sensitive entries.
- A public-facing portal disables broad table access so that anonymous users can submit forms without reading stored records back from the table.
- A low-code app combines portal permissions with API access, requiring the same data scope to be enforced outside the portal as well as inside it.
The main tradeoff is usability versus containment. Broad permissions simplify portal development and reduce support friction, but they also increase the chance that records become reachable by users who should only see a narrow slice of data.
Security Implications
When table permissions are misconfigured, the failure is usually not subtle: data that should be segmented becomes discoverable, queryable, or writable by the wrong audience. That can expose personal data, internal case notes, operational records, or workflow state through a portal that was intended to be limited in scope.
Misapplied permissions also create integrity risk. If write or delete actions are broader than intended, users may alter records outside their authority, causing inaccurate case handling, broken approvals, or corrupted operational evidence. Where API access exists alongside the portal, a weak permission model can be reused across multiple entry points and increase the blast radius of a single mistake.
A practical warning sign is when permission rules rely on broad groups, default inheritance, or assumptions about the portal front end instead of explicit record scope. In those cases, security review should focus on what the user can actually reach, not what the interface appears to hide.
Domain and Governance Relevance
Table permissions matter in identity and access governance because they translate role, relationship, and audience decisions into actual data reach. In low-code environments, the control often becomes the main policy boundary for external users, contractors, and internal reviewers who do not need full table visibility.
Where non-human identities are part of the portal flow, table permissions also shape machine access. Service principals, integration accounts, and automation tokens can inherit more reach than intended if the portal design assumes only human users will call the table. That makes ownership and periodic review important, especially when records support case management, service requests, or other sensitive workflows.
For NHIMG, the core governance question is simple: does the table permission model match the real audience and the real data sensitivity, or does it merely mirror the portal’s convenience model? If those differ, the control is not doing its job.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and MITRE ATT&CK address the attack and risk surface, while CIS Controls v8 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| CIS Controls v8 | 6 — Access Control Management | Table permissions are a direct access-control boundary for portal data. |
| Recommendation — Enforce least privilege on portal tables and review access paths for overbroad reach. | ||
| NIST CSF 2.0 | PR.AC — Access Control | Portal table permissions determine who can access records and perform actions. |
| Recommendation — Apply access-control policy to ensure portal users can only reach authorized records. | ||
| OWASP Non-Human Identity Top 10 | NHI-01 — Non-Human Identity Inventory and Ownership | API and automation accounts can widen table access through portal integrations. |
| Recommendation — Inventory non-human access paths that can read or modify portal tables and assign ownership. | ||
| MITRE ATT&CK | T1190 — Exploit Public-Facing Application | Misapplied portal permissions can expose data through a reachable application surface. |
| Recommendation — Hunt for exposed portal endpoints where weak permissions enable unauthorized record access. | ||
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 7, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
