API security: authentication is not authorization

Define the trust boundary of an API

An API receives data from clients that it does not fully control. Even though the official interface doesn't display a button, a person can send a different request, change an ID, or add a field. The server must therefore consider the entries as unreliable and apply its own rules. This logic concerns internal applications as well as public services. Start by inventorying resources, operations, and user profiles. An understandable security policy describes who can do what on what data, then specifies how this decision is verified.

Authenticating does not mean giving all rights

Authentication establishes an identity using a session, token, or identity provider. Check validity, expiration, and expected properties depending on the mechanism used. Don't trust a simple decoded value without proper validation. A recognized identity does not automatically have rights to all resources. Session management must provide for disconnection, expiration and revocation as necessary. Use HTTPS and protect secrets. Tokens should not appear in URLs or logs where they could be stored and distributed unintentionally.

Authorize at object and operation level

A user may have the right to view their invoices without reading those from another account. Each access by identifier must be controlled. The classic case is to replace a number in the URL and get another record because the server only checks the connection. The permission must also distinguish actions: read, modify, export or delete may require different rights. General permissions are useful, but are not always sufficient to represent ownership or context. The decision must be applied at the time of operation, not just when opening the screen.

Properly isolate organizations from a SaaS

In a multi-organization application, each request must remain within the authorized scope. The organization identifier transmitted by the browser is not proof of membership: it must be compared with the authenticated user and the system rules. This isolation also concerns searches, exports, files, caches and background processing. Proper control on the main route is not enough if an export forgets the filter. Explicitly test two organizations with similar data. Database mechanisms can provide additional isolation, but their configuration and limitations must be understood.

Validate fields and limit changes

Define accepted properties and type, format, length, and volume constraints. A profile editing API should not silently accept a field giving an administrator role. Avoid directly applying a received object to a persisted entity without selecting the allowed properties. Syntactic validation does not replace business rules: a positive quantity may exceed the stock or authorized limit. Also check file formats and storage paths. The identifiers and names provided by the customer must not allow the user to leave the intended scope.

Protect resources from misuse

A legitimate query can be expensive if it requires a huge list, a full export, or repeated AI generation. Limit sizes, frequencies and budgets based on operations. A single limit for the entire application may be too strict for reading and too broad for sensitive action. Mechanisms should consider accounts, organizations, and context without creating an easy method to block other users. Monitor errors and abnormal volumes. Limits protect availability and costs, but do not replace authentication or authorizations.

Secure exchanges with other services

Integrations often use technical keys or accounts. Grant minimal permissions and store secrets in suitable mechanisms. Check outgoing call destinations to prevent a user setting from forcing the server to contact an unexpected internal resource. Webhooks must be authenticated or verified according to the provider's contract, and repeated messages must be handled without duplicating actions. A remote response remains data to be validated. The fact that a service is a partner does not exempt you from controlling the formats, sizes and errors it may return.

Example: testing access to a customer file

Create two accounts in two organizations, then a record in each. With the first account, check reading, modification, deletion and export of its own file. Repeat with the identifier of the second: all prohibited operations must be refused without data leakage. Then test the lists, searches, and associated files. Add a user with reduced rights in the same organization to verify operation distinctions. This scenario often reveals more real weaknesses than a test that only confirms that a valid token allows a route to be called.

Log and respond to incidents without further exposure

Keep useful events: sensitive operation, identity, result and correlation identifier. Avoid secrets, passwords and extensive content that is not necessary for the investigation. Limit access to logs and set their retention period. Prepare for key rotation and revocation of compromised sessions. Errors returned to clients must be controlled so as not to disclose traces, requests or configuration. A response procedure should outline how to contain the problem and verify the extent of access, without relying on a single person.

Integrate security into daily development

Formalize permission rules with business people and add negative tests to critical paths. Re-evaluate rights when a new feature or integration arrives. Security libraries help, but don't automatically know the boundaries of your activity. Tuplify Studio can implement authentication, roles, organization isolation and validation in your CRM and APIs. Security must be verifiable in actual behaviors. An interface that appears locked or a list of known dependencies is no substitute for controls that are systematically applied to protected resources and operations.

Workshop: building a verifiable authorization matrix

List sensitive resources and possible operations, then associate each profile with expected permissions. Add context: owner, organization, file status and special conditions. Turn important combinations into tests, including rejections. For an invoice, check reading, downloading, modification and export: a single protected route does not cover all access routes. Also test asynchronous processing that reuse identifiers. This matrix allows business and technical people to share a clear definition of rights. It serves as a reference for a new functionality and prevents permissions from being decided solely by the buttons present in a model.

Frequently asked questions: tokens and trust

Is a JWT automatically safe? Its security depends on its validation, its management and the use of the information it contains. Decoding a string is not enough to trust it.

Does CORS protect the API against all clients? It regulates certain accesses carried out by browsers. It does not replace authentication or authorization for clients capable of sending requests directly.

Can an internal API do without controls? Errors, compromised accounts and data movement also exist within an organization. Adapt protections to the risk and apply minimum rights. Network location alone does not prove that a request is legitimate for each resource.