CSRF Protection and Server-Side Authorization in QCSB
This article explains Joomla token validation plus server-side plan, user, Workspace, role, source and destination rechecks for mutating operations.
What you need to know
- Basic includes Local storage and the first active Workspace. Pro adds FTP/SFTP, multiple Workspaces, advanced permissions, and background continuation. Max/All Access adds Google Drive, OneDrive, Private Connections, Recovery Vault management, and bulk operations.
- A plan gate decides whether a feature exists at the current Effective tier. Joomla access and QCSB permission rules separately decide whether a particular user may use that feature.
Two separate protections
| Layer | Purpose |
|---|---|
| Joomla CSRF token | Confirms a state-changing request was submitted through a valid Joomla form/session context. |
| QCSB authorization | Re-resolves the current plan gate, user, Workspace, Joomla group/role, connection override, source/destination direction, root and item reference before the action is allowed. |
Why hidden buttons are not security
The frontend may hide or disable actions a user cannot perform, but QCSB does not rely on that presentation. A crafted URL, changed form field, or JavaScript request still goes through server-side authorization and provider/root validation.
Community Discussion
For practical QCSB workflows and discussion with other Joomla site owners, visit the QC Storage Bridge Community. For private support, bug reports, account-specific entitlement issues, or feature requests, use the QuantaCade support system.