playbooks

home / skills / makfly / superpowers-symfony / symfony-voters

symfony-voters skill

/skills/symfony-voters

This skill strengthens Symfony authorization and validation boundaries with test-backed voters, ensuring secure, consistent access decisions across controllers

npx playbooks add skill makfly/superpowers-symfony --skill symfony-voters

Review the files below or copy the command above to add this skill to your agents.

Files (2)
SKILL.md
1.1 KB
---
name: symfony:symfony-voters
allowed-tools:
  - Read
  - Write
  - Edit
  - Bash
  - Glob
  - Grep
description: Strengthen Symfony authorization and validation boundaries with explicit, test-backed enforcement. Use for symfony voters tasks.
---

# Symfony Voters (Symfony)

## Use when
- Hardening access-control or validation boundaries.
- Aligning voters/security expressions with domain rules.

## Default workflow
1. Map actor/resource/action decision matrix.
2. Implement voter/constraint logic at the right boundary.
2. Wire checks at controllers and API operations.
2. Test allowed/forbidden/invalid paths comprehensively.

## Guardrails
- Avoid policy logic duplication across layers.
- Do not leak privileged state via error detail.
- Preserve explicit deny behavior for sensitive actions.

## Progressive disclosure
- Use this file for execution posture and risk controls.
- Open references when deep implementation details are needed.

## Output contract
- Security boundary updates.
- Integration points enforcing decisions.
- Negative-path test results.

## References
- `reference.md`
- `docs/complexity-tiers.md`

Overview

This skill strengthens Symfony authorization and validation boundaries by defining explicit voter and constraint enforcement with accompanying tests. It guides mapping actor/resource/action matrices, placing logic at the correct boundary, and wiring checks into controllers and API operations. The result is reproducible security boundary updates and negative-path test coverage.

How this skill works

The skill inspects application decision points and prescribes a voter or validation constraint where domain rules belong. It produces integration points for controllers and API endpoints, and generates tests that assert allowed, forbidden, and invalid flows. Outputs focus on concrete changes: updated security boundaries, enforcement hooks, and failing negative-path tests.

When to use it

  • Hardening access control for sensitive resources or actions
  • Ensuring security expressions align with domain authorization rules
  • Removing duplicated policy logic across service and controller layers
  • Introducing explicit deny behavior for high-risk operations
  • Adding negative-path tests to prevent regressions in authorization

Best practices

  • Map an actor/resource/action decision matrix before implementing voters
  • Implement voters and validation constraints at the domain boundary, not in UI code
  • Wire checks consistently in controllers, API operations, and message handlers
  • Write tests for allowed, forbidden, and invalid cases to document intent
  • Keep error responses generic for forbidden paths to avoid leaking privileged state

Example use cases

  • Create a Voter to centralize edit permissions for a multi-tenant resource
  • Replace scattered role checks with a single domain voter tied to business rules
  • Add a validation constraint to reject malformed requests before business logic runs
  • Introduce integration tests that assert endpoints return 403 for forbidden users
  • Enforce explicit deny for destructive actions and log denial reasons for audit

FAQ

When should I choose a Voter over a simple role check?

Use a Voter when decisions depend on actor, resource state, or complex business rules; use role checks only for coarse-grained, static access controls.

How do I avoid duplicating policy logic?

Centralize rules in Voters or constraints and call them from controllers, services, and message handlers rather than reimplementing checks in multiple places.