Authentication and authorization: protecting the right data from the wrong user

Authentication answers who is making a request. Authorization answers whether that identity may perform this action on this particular resource. A login screen can work perfectly while an application still exposes another customer’s data if the server does not make the second decision correctly.

Model access around objects and actions

For each sensitive record and action, state which tenant, role, relationship, or explicit grant permits access. Apply that decision on the server for every request that reads, changes, exports, or deletes data. Do not rely on a hidden button, client-side route check, or an identifier that appears difficult to guess as an access-control boundary.

Protect the session that carries identity

OWASP recommends cookies as the preferred session-ID exchange mechanism and describes the value of HTTPS plus Secure, HttpOnly, and SameSite cookie attributes. It also warns against placing session IDs, JWTs, refresh tokens, or credentials in localStorage or sessionStorage because script running in the origin can access them. The right implementation depends on the product architecture, but the choice should be deliberate and tested.

Test the negative cases

• Attempt the same action as a signed-out visitor, a basic user, an administrator, and a user from another tenant.
• Change object identifiers and request methods directly rather than only testing through the interface.
• Verify that denied requests fail closed without leaking private data.
• Test session expiry, logout, privilege changes, and recovery paths.

Kiwi can help define and implement access-control requirements in an agreed product scope. Security review depth, identity-provider selection, compliance duties, and incident response remain project-specific.