Qlik Security Review

Qlik Cloud’s Can publish role lets someone push content into a managed space without ever holding the Can view, Can contribute or Can consume data role needed to open what is inside it, and Qlik’s own documentation confirms it.

In Qlik Cloud, the role that publishes content is not the role that can open it

Qlik Cloud content lives inside one of four space types, personal, shared, managed or data, and each carries an entirely separate set of roles. Qlik’s own documentation on space roles lists Owner, Can manage, Can edit, Can edit data in applications, Can view and Can consume data in a shared space, then adds Can publish, Can contribute, Has restricted view and Can operate for a managed space, plus a separate Is owner, Can edit and Can consume data set for a data space. In a managed space, the Can publish role can push applications in without ever holding the Can view, Can contribute or Can consume data role needed to open what was just published, a deliberate split for teams who build against mock data before production content goes live. We map who actually holds each role in every space against who the business meant to have viewing, editing, publishing or managing rights.

Section Access is the mechanism Qlik’s own support articles call the section access table, a script-loaded table that reduces what a signed-in user can see once an app opens. That documentation is specific about how it fails: a reload is rejected outright if the person running it lacks ADMIN in the table’s ACCESS column, if the ACCESS, USERID or USER.EMAIL column name is wrong, or if the field values are not upper case, and a separate Qlik support article confirms a wildcard star in any other field of that table means every value is visible, so a real value in its place is what actually restricts a row. The same documentation notes Section Access can key off an Active Directory group or user name directly, though certain characters break the match entirely. We test every ACCESS, identity and reduction field in the table against the accounts people actually sign in with today, not the accounts the rule was written for.

Access to the Qlik Cloud APIs runs through OAuth2, JWT or API keys, and Qlik’s own developer documentation draws a hard line between them: an API key authenticates with the same permissions as the user who created it, and because API keys do not support scopes, a key with full user-level access cannot be narrowed to least privilege, only rotated or revoked after the fact. A Machine-to-Machine OAuth2 client is different again, since Qlik states it always carries the Tenant Admin role with no user interaction required, and an Impersonation-enabled M2M client can additionally authenticate as any user by userId or subject. Underneath all three sits one trust boundary: Qlik’s documentation states that an API operation not exposed in the interface is reachable by design once the caller holds the matching scope or role, the same lesson behind hidden fields in our Power BI reviews. We test what every API key, OAuth client and custom role actually reaches, not what the interface chooses to show.