Bollard UI

Docs

Security

Please report security problems privately. Bollard UI components are UX guard rails; your server still has the final say.

Report a vulnerability

Don't post security problems publicly. Email tusharkhadde06@gmail.com with “Bollard UI security” in the subject. Include:

  • the component (or the docs site) and when you installed it,
  • what an attacker can do and how,
  • steps or a minimal example to reproduce it.

You can expect an acknowledgement within 3 working days and an update on the fix within 14 days. Once a fix ships you'll be credited in the changelog, unless you'd rather stay anonymous.

Scope

In scope: a component that leaks data it was meant to protect (for example a secret field or paste guard that exposes the value), cross-site scripting through component props or rendered content, and anything in the docs site or registry files that could harm visitors or people installing components.

Out of scope: components used in ways their docs warn against, a guard rail being bypassed by someone who controls the browser (that is expected; see below), and issues in third-party dependencies (report those upstream, and tell us if a component needs updating).

Several demos contain fake, deliberately invalid keys (such as AKIAIOSFODNN7EXAMPLE) to show secret detection. They aren't real credentials.

Supported versions

Components are source you copy, so fixes land in the registry at https://bollard-ui.vercel.app/r/<name>.json. Only the latest version of each component is supported. To pick up a fix, re-run the add command for that component and review the diff (how to update).

Guard rails vs enforcement

Everything here runs in the user's browser. A cooldown, a type-to-confirm dialog, a two-person approval screen or a secret-paste warning helps honest users avoid mistakes; it cannot stop someone who edits the page, opens a new tab, clears storage or calls your API directly.

Enforce the same rule on the server, where it can't be skipped:

  • validation and database constraints for values,
  • authorization and re-authentication checks for sensitive actions,
  • rate limits and cooldowns for repeat actions,
  • idempotency keys for payments and other submits that must happen once,
  • approvals recorded and checked by the backend for two-person rules and agent tool calls.

Component pages with a server-side note say exactly what to enforce. For example: Agent Action Approve, MCP Tool Review, Reset Hard Readback, Account Deletion Readback, Force Push Confirm, Infra Plan Readback, Recovery Contact Cooldown, Migration Preview.