Assign the minimum permissions needed for common FeraRender roles.

Overview

Assign the minimum permissions needed for common FeraRender roles. Use least privilege and treat rendered data as confidential. Security controls must be tested whenever routes, XSLT capabilities, upload handling, or tenant resolution changes.

Key points

• Readers need VIEW.TEMPLATE.
• Template managers need EDIT.TEMPLATE.
• Render clients need CAN.RENDER.
• Native XSLT authors may need EDIT.TEMPLATE.XSLT.
• Service accounts should receive only the routes and instances they require.

Recommended procedure

1. Identify the role or service account.
2. Grant only the required tenant and feature permissions.
3. Confirm audit and error logging.
4. Review data retention, secrets, and downstream service exposure.

Security checklist

• Apply least privilege to users and service accounts.
• Confirm the instance boundary on every data-management and render route.
• Keep transforms deterministic and isolated from files, networks, scripts, and environment secrets.
• Redact confidential XML and rendered content from routine logs.
• Review retention and deletion requirements for templates, resources, logs, and generated files.

Troubleshooting

A user can see too much

Review tenant resolution, global ownership, role permissions, and any request-body owner override.

Logs contain sensitive document data

Redact request bodies and downstream responses and apply a documented retention period.

A transform is rejected as unsafe

Rewrite it to use only supplied input data and permitted deterministic XSLT instructions.

Related documentation

• Tenant Administration and Isolation
• FeraRender Security Model
• Audit Actions and Error Logging

Documentation source: feradelinc/feradel.render.api, reviewed against repository revision b2c3a710. Verify behavior against the deployed release before publishing exact routes, limits, or version requirements.