Use this skill when v22 behavior changes could alter the attack surface or create unsafe assumptions around server and template boundaries.
Scanned 10/2/2026
npx -y skills add janpereira-dev/ngAutoPilot --skill angular--security--angular-v22-security-and-server-boundaries --agent claude-codeInstalls into .claude/skills of the current project.
Are you the author of Angular Security Angular V22 Security And Server Boundaries?
Add the live security badge to your README — it updates automatically with every re-scan.
[](https://www.skillsdirectory.com/skills/janpereira-dev-angular-security-angular-v22-security-and-server-b)More formats (shields.io, HTML) on the badges page. Keep it an A: scan every change in CI with Pro.
---
id: angular.security.angular-v22-security-and-server-boundaries
name: Angular v22 Security and Server Boundaries
description: >
Use this skill when v22 behavior changes could alter the attack surface or create unsafe assumptions around server and template boundaries.
stack:
- Angular
- TypeScript
category: security
status: stable
version: 0.10.0
owner: NgAutoPilot
triggers:
- security
- data-*
- SSR security
- server transport
- redirect safety
compatibility:
angular:
min: "22"
---
# Angular v22 Security and Server Boundaries
## Purpose
Use this skill when v22 behavior changes could alter the attack surface or create unsafe assumptions around server and template boundaries.
## When to Use
Use this skill when:
- Template bindings changed in a way that may hide or reveal data flow.
- SSR or platform-server code needs a safer transport path.
- Redirect handling or DOM binding semantics are part of the review.
## When Not to Use
Do not use this skill when:
- The issue is a generic XSS review.
- The task is only about rendering correctness.
- There is no security-relevant surface in the change.
## Required Inputs
- template bindings
- SSR transport
- platform-server configuration
- router redirects
## Procedure
1. Inspect any data-* and attribute bindings that changed meaning.
2. Confirm server-side requests use the safer default transport path.
3. Check redirects, headers, and request forwarding for unintended exposure.
## Do
- Prefer explicit bindings over accidental magic.
- Keep server transport predictable.
- Treat redirects and forwarded headers as security-sensitive.
## Do Not
- Do not rely on deprecated or ambiguous binding behavior.
- Do not keep server XHR paths if the safer default is available.
- Do not assume a routing change is harmless just because it compiles.
## Review Checklist
- [ ] No unsafe binding assumptions remain.
- [ ] Server transport is explicit.
- [ ] The security impact was validated.
## Expected Output
1. A security boundary summary.
2. The risky surface that changed.
3. The safer replacement path.
Is this your skill, or is something wrong with this listing? Request removal or report an issue. Author removals are honored within 72 hours.
No comments yet. Be the first to comment!