home / skills / makfly / superpowers-symfony / api-platform-security

api-platform-security skill

/skills/api-platform-security

This skill helps design explicit API Platform contracts in Symfony, aligning operations, serialization, validation, and security with risk aware, versioned

npx playbooks add skill makfly/superpowers-symfony --skill api-platform-security

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

Files (2)
SKILL.md
1.2 KB
---

name: symfony:api-platform-security
allowed-tools:
  - Read
  - Write
  - Edit
  - Bash
  - Glob
  - Grep
description: Deliver robust API Platform contracts in Symfony with explicit operations, mapping, and policy-safe behavior. Use for api platform security tasks.
---

# Api Platform Security (Symfony)

## Use when
- Designing or evolving API Platform contracts and operations.
- Aligning serialization, validation, and security behavior.

## Default workflow
1. Define operation-level contract and payload boundaries.
2. Implement resource/DTO/provider/processor changes with explicit mapping.
2. Apply operation-specific validation and security constraints.
2. Validate functional behavior across happy and negative paths.

## Guardrails
- Keep API contract explicit and version-aware.
- Avoid exposing internal entity fields implicitly.
- Prevent drift between docs and actual serialization.

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

## Output contract
- API artifacts changed (resource/DTO/provider/processor).
- Contract/security decisions and rationale.
- Functional verification results.

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

Overview

This skill delivers robust API Platform contracts in Symfony with explicit operations, mapping, and policy-safe behavior. It helps you define operation-level boundaries, implement DTOs/providers/processors, and align serialization, validation, and security. The goal is predictable, version-aware APIs that avoid accidental exposure of internal entity fields.

How this skill works

The skill inspects your resource definitions and operation configurations, then suggests explicit contracts and payload mappings. It identifies gaps between serialization groups, validation rules, and security expressions, and recommends code-level changes to providers, processors, or DTOs. Finally, it produces a concise output contract listing artifacts changed, security decisions, and functional verification results.

When to use it

  • Designing or evolving API Platform resources and operations
  • Aligning serialization groups, validation, and security expressions
  • Preventing implicit exposure of internal entity fields
  • Preparing a version-aware contract for client integration
  • Auditing API behavior across happy and negative paths

Best practices

  • Define operation-level DTOs to decouple API payloads from entities
  • Keep contracts explicit and track version changes in the API spec
  • Apply validation and security rules at the operation level, not only at the entity
  • Map providers and processors clearly so behavior is predictable
  • Run functional checks for both permitted and denied access scenarios

Example use cases

  • Creating a PATCH operation with a dedicated DTO and processor to restrict writable fields
  • Migrating an entity-backed resource to use read-only DTOs for responses
  • Auditing a collection endpoint for leaked internal fields through serializer groups
  • Implementing operation-specific security expressions that differ between GET and POST
  • Documenting contract decisions for a breaking change prior to a new API version

FAQ

What output will I get after running the skill?

You will receive a list of API artifacts changed (resources/DTOs/providers/processors), the security and contract decisions with rationale, and functional verification results for key paths.

Does it modify entities directly?

No. The recommended approach is to introduce DTOs, explicit mappings, or providers/processors rather than exposing or modifying internal entity fields directly.