An integration between an online store, a CRM, an ERP, or a support tool is often granted authorization that is described too broadly: “access to orders” or “access to the CRM.” This simplification makes it difficult to know what the connector actually needs and may leave functions or data available that are not part of its work.
The permission matrix for APIs turns this generic access into concrete, reviewable decisions. Its usefulness is not limited to the technical team: operations can validate the process, the business can approve sensitive actions, and providers can understand the boundaries of their involvement. The aim is for each actor, human or automated, to access only the operations, records, and fields required.
The Problem with Authorizing an Entire Tool
Being authenticated identifies a person, process, or technical account, but it does not by itself determine what that entity can do. Authorization must answer, at a minimum, whether that actor can perform a specific action and on which resource. For example, a connector that creates contacts from a form does not necessarily need to export all contacts, change owners, delete records, or view internal information. [2]
It is also necessary to distinguish permission for a function from permission for a specific object. The fact that a portal allows orders to be viewed does not mean that any customer can view any order: the system must verify that the requested record belongs to that customer’s company or account. OWASP identifies the absence of this object-level check as a risk that can lead to unauthorized exposure, modification, or deletion of data. [1]
What an Operation-Based Permission Matrix Should Include
A matrix is a structured inventory of access decisions. Each row represents an operational need, not a generic role such as “administrator” or “full access.” It can start with a critical integration, such as web–CRM, e-commerce–ERP, or customer portal–support, and then be expanded to the rest of the ecosystem. Its value lies in making exceptions visible before they are turned into credentials or technical rules.
As a minimum template, include the system or integration; the actor; the resource; the operation; the scope; the permitted and excluded fields; the authentication method and associated credential; additional conditions; the responsible person; the review date; and the event that must be logged. Operations should distinguish between reading, creating, updating, cancelling, approving, exporting, and deleting, because their impact is not equivalent.
- Actor: employee, customer, provider, automated process, or service account.
- Scope: own data, a specific company, a business unit, or internal data.
- Condition: for example, assigned orders only, documents in a specific status only, or prior approval for exporting.
Hypothetical Example of a Web–CRM Integration
Hypothetical example: a company connects the sales enquiry form on its website to the CRM. The form’s technical account can create a contact and a lead, but only with name, email, company, telephone number, and message. It cannot read existing contacts, download lists, change the sales owner, view internal notes, or delete records. The business owner validates that these fields are sufficient to handle the enquiry.
The same matrix must describe the scope of the data. If the CRM organizes customers by subsidiaries, the automated process should create records only in the assigned unit, not in all of them. If it needs to detect duplicates, it may require a limited, logged check rather than global read access. This precision prevents a legitimate need from becoming a credential with unnecessary capabilities.
Five Rules for Turning the Matrix into Real Controls
First, apply deny by default: every operation that is not explicitly authorized must be rejected. Second, check both the action and the requested object on the server and with every request; hiding a button in the interface or validating permission only when a token is issued is not enough. Third, separate people’s accounts from technical accounts so that their capabilities can be limited, reviewed, and removed independently. [2]
Fourth, limit each integration account to the resources, operations, and fields required by the process. Fifth, establish periodic reviews and reviews triggered by relevant changes, such as a provider leaving, a change in responsibilities, a new endpoint, or a replaced automation. Managing the account life cycle includes recording account creation, changes, enablements, and removals, as well as disabling accounts that no longer correspond to a person or current need. [4]
- Avoid shared keys between different providers or automations.
- Assign a business owner for sensitive permissions, even if technology implements the control.
- Log permission changes and relevant actions by technical accounts to make review easier.
How to Validate and Maintain the Matrix
Before publishing changes, turn the matrix into test cases. With explicit authorization, defined scope, and preferably test accounts or data, confirm that every permitted action works and that every action not granted is rejected. Check both query and modification operations, and test roles or accounts with the least privilege. The review must be defensive, planned, and limited to the authorized environment and systems. [3]
A useful review does not seek to prove that the system “is secure” in absolute terms. It seeks to identify differences between the approved process, the documented matrix, and the actual behaviour of the API, the administrative panel, and the website. If a rule differs between channels, if a technical account has administrator permissions as a precaution, or if a connector can export data it does not use, the design should be corrected and the change validated again. [1] [3]
Frequently asked questions
What is the difference between authentication and authorization in an API?
Authentication verifies the identity of the party making a request, such as a user or an integration account. Authorization decides which operation that identity can perform, on which resource, within what scope, and under which conditions. Both are necessary.
Does each integration need its own account?
In general, separating technical accounts by integration makes it easier to limit permissions, log activities, and remove access when a process changes or is no longer used. A shared account can make it difficult to attribute actions and apply specific limits.
Which integration should be used to start the matrix?
Start with a critical integration or one that handles relevant data, such as the connection between the website and CRM, the store and ERP, or the customer portal and support. Document the actual operations, validate the limits with the business and technology teams, and use the result as a model for the other integrations.