Tiki's Plugin Approval Boundary Starts With Group Permissions

Tiki Wiki CMS Groupware combines a wiki, file galleries, trackers, and a plugin system. Some plugins can render external content, query a database, or include server-side resources. Tiki has an approval mechanism for potentially unsafe plugins, but that mechanism depends on the group permissions that allow a user to approve or use those plugins.

Historical title observation

An AutoPR count-only observation recorded on 3 November 2026 found 1,828 matches for title="Tiki" with sub_type=all, page 1, and pagesize 1. The term is short and the historical count is not a confirmed Tiki population. Use it as a lead only, then verify the product through page structure, API behavior, and version details.

API tokens inherit user groups

Tiki's API documentation says API access can be enabled with auth_api_tokens and that permission configuration is based on the Tiki user's groups. A token is not a separate authorization universe. If a service account belongs to a group with broad plugin or content permissions, a copied token inherits that authority.

Inventory tokens by owning user and purpose. Review the user's group memberships, including inherited groups. Test a token with the minimum intended permissions and confirm that it cannot approve a plugin, edit a tracker, or access a file gallery outside its scope. Revocation should disable the token and remove the user from the relevant group if the identity is no longer needed.

Plugin approval is a workflow

Tiki's plugin security documentation says a potentially insecure plugin must be approved by someone with the appropriate permission. The approval page describes preview and validate/reject actions. A safe deployment separates the editor who drafts content from the reviewer who approves a risky plugin.

Check who holds the approval permission and whether the group is small enough to review. Confirm that approval events are logged and that the reviewer sees the actual plugin input and arguments. A blanket approval of every plugin from a privileged account can turn the workflow into a formality.

Object and category permissions

Tiki permissions can be applied by group and can be overridden by object or category rules. Documentation notes that an administrative permission on a feature may be lost for an object with local permissions or category rules. Test the effective result for a page, file, tracker, or comment, not just the global feature setting.

Review the anonymous and registered groups first. These are common sources of unintended access. Then review the admin group and any group that can approve plugins, upload files, or change site-wide configuration. Use the permission enforcement order and the actual object path when troubleshooting a discrepancy.

Verification checklist

• Confirm the Tiki version and exposed URL.
• Enable and scope API tokens deliberately.
• Review inherited group permissions for token owners.
• Separate editing from plugin approval.
• Test category and object overrides on representative content.
• Monitor token use, permission changes, and plugin approvals.

The historical title count is a discovery lead. The security boundary is the group permission model and the approval workflow behind the wiki.

References

• Tiki API documentation
• Tiki permissions
• Tiki plugin security
• Tiki plugin approval
• Tiki token access