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 record-level and action-level controls that determine whether portal users can see, create, edit, or delete data in a low-code or external-facing portal. In NHI security, they matter because the portal often mediates access through service-to-service calls, delegated tokens, or embedded application identities rather than a human session alone.
Definitions vary across vendors, but the security intent is consistent: restrict data exposure to the smallest audience and action set that the workflow requires. Good table permissions work alongside authentication, row filtering, and API authorization. They are not the same as making a page private, and they are not a substitute for backend authorization checks. For a broader NHI framing, see OWASP Non-Human Identity Top 10 and NHIMG’s Ultimate Guide to NHIs, which places authorization failures in the context of sprawling machine access.
The most common misapplication is treating table permissions as a cosmetic portal setting, which occurs when teams assume page visibility automatically enforces record security.
Examples and Use Cases
Implementing table permissions rigorously often introduces workflow friction, requiring organisations to weigh faster self-service publishing against tighter control over who can read or change records.
- A customer support portal allows authenticated users to submit tickets, but table permissions restrict them to their own cases while support staff retain broader update rights.
- A partner portal exposes pricing requests only to assigned accounts, preventing one partner from viewing another partner’s confidential records.
- An internal operations app lets an automation identity write status updates to a table, but only a privileged admin role can delete records. This aligns with guidance in NIST SP 800-53 Rev. 5 Security and Privacy Controls.
- A low-code portal uses table permissions to block anonymous access to incident data, while API access remains separately governed to stop direct retrieval by token-bearing clients.
- NHIMG’s Replit AI Tool Database Deletion illustrates why delete permissions must be narrowly scoped when agents or automations can act on live records.
Why It Matters in NHI Security
Table permissions are an NHI control because NHIs often sit behind portals, pipelines, and integrations that can bypass human expectations of “private” data. When permissions are too broad, service accounts, API keys, or embedded agents can read or mutate records far beyond their intended scope. NHIMG’s Ultimate Guide to NHIs notes that 97% of NHIs carry excessive privileges, which is exactly the condition that makes weak table permissions so dangerous.
This matters most when a portal is linked to automation or external sharing. A misconfigured table can become a silent exposure path even if login controls appear sound, because the data layer and the presentation layer are not enforcing the same boundary. The same issue shows up when portal permissions and API permissions diverge, or when an agent inherits broader access than the user who triggered it. NHIMG’s Microsoft SAS Key Breach shows how overly broad access mechanisms can quickly widen blast radius.
Organisations typically encounter table-permission failure only after exposed records, unexpected deletions, or partner complaints, at which point the control becomes operationally unavoidable to address.
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 CSA MAESTRO address the attack and risk surface, while NIST SP 800-63, NIST CSF 2.0 and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-02 | Covers improper access and secret misuse that enable overbroad portal data exposure. |
| NIST SP 800-63 | Identity assurance informs whether a portal identity should be trusted for data access. | |
| NIST CSF 2.0 | PR.AC-4 | Least-privilege access control directly applies to table permissions in portals. |
| NIST Zero Trust (SP 800-207) | Zero Trust requires explicit authorization at the data layer, not just portal login. | |
| CSA MAESTRO | Agentic workflows need bounded tool and data access to prevent unintended record changes. |
Review portal table entitlements regularly and remove any access not required for current operations.
