How to Stop Permission Creep Using Role-Based Toolbar Access

You’re building a document management system. Your first instinct is simple: editors can do everything, and everyone else is locked out. But then requests start arriving.

Legal needs to export PDFs. You make them editors. A week later, you realize they’ve accidentally deleted three documents.

Finance needs to print reports. You add them to the editor role too. Now they’re changing numbers.

Customer success wants to view documents in fullscreen during calls. You give them editor access because that’s the only way to unlock fullscreen. They’re now modifying customer contracts.

Each time, the reasoning is the same: “We just need them to have access to one thing.” Each time, you grant a role full editing permissions because your editor only understands two states — completely on or completely off. There is no middle ground.

This is permission creep. It happens in almost every content application. You end up with too many people who can edit, which means you need auditing, version history, and approval workflows just to contain the damage. Your security posture degrades. Your data integrity suffers. And your codebase fills with conditional logic trying to patch the gap between what people actually need and what your permission system can offer.

The root cause is a false equivalence: Can edit should never mean can print, export, view source, or take any other action. These should be independent permissions. But most editors — including Froala by default — conflate them. You unlock one button, you unlock everything.

Froala’s toolbarButtonsEnabledOnEditorOff solves this. It lets you lock content for editing while preserving a granular whitelist of allowed actions. The result is a permission model where you never again have to grant someone full editing access just to unlock one button.

Key Takeaways

• Permission creep happens when you conflate “can edit” with every other action. Most editors force you to choose: full access or nothing. This creates pressure to over-grant permissions.
• Break the tie with toolbarButtonsEnabledOnEditorOff**.** You can now lock editing while keeping specific buttons active—print, export, approve, archive, whatever your workflow needs.
• Design your permission model before coding. Create a role-to-action matrix, get stakeholder alignment, then implement. This prevents ad-hoc decisions from accumulating.
• Centralize permissions in code. One rolePermissions object. One getPermissions() function. Reference it everywhere. Make it the source of truth.
• Always validate on the backend. The frontend toolbar is UX guidance, not a security boundary. Your server must enforce every permission independently.
• Default to the most restrictive access. Unknown roles get minimal permissions. Missing auth fails closed. Unrecognized states lock everything down.

The Permission Creep Trap

Here’s what typically happens. You start with a simple role system:

• Editor: can edit everything
• Viewer: can see everything, can’t do anything

This works for two weeks. Then:

• Legal asks to export PDFs → you make Legal an editor
• Finance asks to print → you make Finance an editor
• Support asks for fullscreen mode → you make Support an editor
• A partner needs to view HTML source → you make Partners an editor

Now your “editor” role has seventeen different use cases, and half of them have no business editing content. You’ve created a security surface area you didn’t intend. Worse, you’ve created a maintenance nightmare: every new request forces you to either grant editing access (bad) or tell the user “no” (frustrating).

The fundamental problem is that your editor’s default behavior ties toolbar access to editing access. Turn off editing with edit.off(), and the entire toolbar goes dark. No print button. No export. Nothing. So developers reach for the only lever they have: make people editors.

Understanding the Solution

toolbarButtonsEnabledOnEditorOff breaks that tie. It lets you disable editing while keeping specific toolbar buttons active. Instead of “can edit or can’t do anything,” you now have granular control:

• Editor: full toolbar, can edit
• Legal: read-only, but can export PDFs
• Finance: read-only, but can print
• Support: read-only, but can open fullscreen
• Viewer: completely locked down

Each role gets exactly what it needs. No more, no less. No more false choices between granting full access or granting nothing.

The supported buttons are print, fullscreen, export_to_word, getPDF, and html. You can also define custom buttons (like “Approve,” “Share,” or “Archive”) that stay active in read-only mode. This scales cleanly as your workflows grow.

Building a Permission Model That Doesn’t Creep

The key to avoiding permission creep is to design your roles intentionally before you start coding. Not after the first request arrives — before.

Start by listing every action a user might need to perform in your document editor. Don’t just think about editing. Think about:

• Editing content
• Printing
• Exporting to PDF
• Exporting to Word
• Viewing HTML source
• Fullscreen mode
• Sharing
• Approving
• Rejecting
• Archiving
• Creating versions
• Comparing versions

Then, for each role in your system, decide which actions they should have. Be specific. Don’t say “Legal can do what they need” — say “Legal can export to PDF and print, but cannot edit or delete.”

Write it down. Make it a table. Show it to your product manager, your security team, your legal team. Get alignment before you write code. This prevents a thousand small decisions from accumulating into permission creep.

Implementing the Permission Model

Once your matrix is locked in, translate it into code. Create a single configuration object that mirrors your table.

const rolePermissions = {
  editor: {
    canEdit: true,
    allowedWhenReadOnly: []
  },
  reviewer: {
    canEdit: false,
    allowedWhenReadOnly: ['print', 'fullscreen', 'html', 'approveDocument']
  },
  legal: {
    canEdit: false,
    allowedWhenReadOnly: ['print', 'getPDF', 'export_to_word', 'archiveDocument']
  },
  finance: {
    canEdit: false,
    allowedWhenReadOnly: ['print', 'getPDF']
  },
  viewer: {
    canEdit: false,
    allowedWhenReadOnly: []
  }
};

Keep this object at the top level of your code. Make it easy to find. Make it easy to modify. This is your permission source of truth — if you change the matrix, you change this object and only this object.

Notice a few important details:

• The editor role has an empty allowedWhenReadOnly array because editors aren’t in read-only mode.
• The viewer role has no buttons at all, not even print. Be explicit about the minimum viable access.
• If a role needs a custom action (like approveDocument or archiveDocument), include it here.
• Unknown roles should fall back to viewer (the lowest privilege).

Initializing the Editor with Role-Based Permissions

With your permission object in place, use it to configure Froala at initialization time:

function createEditor(role) {
  // Fallback to viewer if role is unknown
  const permissions = rolePermissions[role] || rolePermissions.viewer;

  new FroalaEditor('#editor', {
    toolbarButtonsEnabledOnEditorOff: permissions.allowedWhenReadOnly,
    events: {
      initialized: function() {
        if (!permissions.canEdit) {
          this.edit.off();
        }
      }
    }
  });
}

// Get the current user's role from your auth system
const currentUserRole = window.currentUser.role;
createEditor(currentUserRole);

This pattern ensures that:

1. The editor starts in the correct state immediately — no flicker, no race conditions.
2. Role logic is centralized — you’re not scattering permission checks throughout your code.
3. Unknown or missing roles default to the most restrictive access — if something goes wrong, users get locked out, not given too much access.
4. Adding a new role is a single-line change: add it to the rolePermissions object.

Loading Roles Dynamically from Your Auth System

In a real application, the role comes from your authentication layer or an API. Load it before initializing the editor:

async function initEditor() {
  try {
    const response = await fetch('/api/current-user');
    const user = await response.json();

    createEditor(user.role);
  } catch (error) {
    // Fail securely: default to viewer if auth fails
    console.error('Failed to load user role:', error);
    createEditor('viewer');
  }
}

initEditor();

Fail securely. If authentication fails or the role is missing, default to the most restrictive role. Never assume access.

Adding Custom Buttons for Workflow Actions

Generic buttons like print and export aren’t always enough. You may need custom buttons for workflow-specific actions like “Approve,” “Request Changes,” or “Archive.”

Define custom buttons the same way you define roles — centrally, in configuration:

// Register custom button icons and handlers
FroalaEditor.DefineIcon('approveDocument', { NAME: 'check', SVG_KEY: 'check' });
FroalaEditor.RegisterCommand('approveDocument', {
  title: 'Approve Document',
  focus: false,
  undo: false,
  refreshAfterCallback: false,
  callback: function() {
    approveDocument();
  }
});

FroalaEditor.DefineIcon('requestChanges', { NAME: 'edit', SVG_KEY: 'edit' });
FroalaEditor.RegisterCommand('requestChanges', {
  title: 'Request Changes',
  focus: false,
  undo: false,
  refreshAfterCallback: false,
  callback: function() {
    requestChanges();
  }
});

// Add these to your role permissions
const rolePermissions = {
  reviewer: {
    canEdit: false,
    allowedWhenReadOnly: ['print', 'fullscreen', 'html', 'approveDocument', 'requestChanges']
  },
  // ... other roles
};

These custom buttons work beautifully in read-only mode. A reviewer can’t edit the document, but they can approve it. Legal can’t change anything, but they can request changes. This is precise permission control.

Document-State-Aware Permissions

Permissions often depend not just on role, but on document status. A document in draft mode might allow edits from anyone with the editor role. Once it’s finalized, only admins can make changes. Combine role and state:

function getPermissions(role, documentStatus) {
  const basePermissions = rolePermissions[role] || rolePermissions.viewer;

  // If the document is finalized, lock down all editing
  if (documentStatus === 'finalized') {
    return {
      canEdit: false,
      allowedWhenReadOnly: basePermissions.allowedWhenReadOnly.filter(
        btn => ['print', 'getPDF', 'fullscreen'].includes(btn)
      )
    };
  }

  // If under review, reviewers can approve but nobody can edit
  if (documentStatus === 'under_review') {
    if (role === 'reviewer') {
      return {
        canEdit: false,
        allowedWhenReadOnly: ['print', 'fullscreen', 'html', 'approveDocument', 'requestChanges']
      };
    }
    return {
      canEdit: false,
      allowedWhenReadOnly: ['print', 'fullscreen']
    };
  }

  // Draft mode: use base permissions
  return basePermissions;
}

// Use it during initialization
const permissions = getPermissions(currentUserRole, currentDocumentStatus);
new FroalaEditor('#editor', {
  toolbarButtonsEnabledOnEditorOff: permissions.allowedWhenReadOnly,
  events: {
    initialized: function() {
      if (!permissions.canEdit) {
        this.edit.off();
      }
    }
  }
});

This prevents permission creep at the workflow level. As your document lifecycle grows, you update getPermissions() once. You don’t scatter state logic throughout your codebase.

The Critical Backend Check

Here’s the part people forget: none of this matters if your backend doesn’t validate permissions.

The toolbar is a UX layer. A determined user can open the browser console and call editor.edit.on(). They can forge API requests. They can do anything the client allows. Your server must independently verify every action.

When a user exports a document, your backend should check: “Does this user’s role allow exports?” When they approve a document, check: “Is this document in a state where approvals are allowed?” When they try to edit, verify: “Can this role edit at this time?”

Never trust the client. The toolbar is for helping honest users understand their access level. It’s not a security boundary.

// Backend example: validating export permissions
app.post('/api/documents/:id/export', async (req, res) => {
  const user = req.user; // from auth middleware
  const document = await Document.findById(req.params.id);
  const userRole = user.role;

  // Check: does this role have export permission?
  const permissions = rolePermissions[userRole] || rolePermissions.viewer;  
if (!permissions.allowedWhenReadOnly.includes('getPDF')) {
    return res.status(403).json({ error: 'Export not allowed for your role' }); 
 }
  // Check: is the document in a state where export is allowed?
  if (document.status === 'draft' && userRole !== 'editor') {    return res.status(403).json({ error: 'Cannot export draft documents' });  }

  // Permission check passed. Now generate the export.
  const pdf = await generatePDF(document); 
  res.download(pdf);});

The pattern: always validate against your permission model on the server. The frontend toolbar is just a convenience — the real enforcement happens here.

Conclusion

Permission creep happens when you treat “can edit” as synonymous with every other action. It’s a false equivalence that forces you to grant full access to solve partial problems.

toolbarButtonsEnabledOnEditorOff lets you break that equivalence. Combined with a clear permission matrix, centralized configuration, and backend validation, it becomes your defense against creep.

The pattern is simple: design your roles intentionally before coding, implement them in one place, validate them on the server, and refuse to add exceptions. Each decision you defer is a decision that will compound. Make them upfront, make them visible, and make them stick.

Your future self will thank you when you’re not maintaining seventeen ad-hoc permissions five years from now.

Try our working demo on JSFiddle, or download Froala and build one yourself.

Originally published on the Froala blog.