docs: add security and sanitization reference to developer skill - #70134
docs: add security and sanitization reference to developer skill#70134aminesbdev wants to merge 2 commits into
Conversation
11eaa61 to
c1ff3df
Compare
| ## The Safe Pipe Pattern | ||
|
|
||
| To avoid repeating `DomSanitizer` calls in TypeScript components, use a **standalone pipe** to bypass security directly within templates. |
There was a problem hiding this comment.
I don't think we've recommended this pattern.
There was a problem hiding this comment.
I agree, even the name wouldn't be right; I wouldn't call it safeHTML because it doesn't sanitize, it just bypasses it.
@Pipe({
name: 'safeHtml',
standalone: true,
})There was a problem hiding this comment.
Perhaps recommending DomPurify as a alternative?
|
I would need to see some metrics on what this skill would actually brings. |
51916dc to
554b134
Compare
@JeanMeche Thanks for the feedback — totally fair ask. Here are the metrics from a local benchmark I ran. MethodologyI built a lightweight eval harness (inspired by skillgrade) that tests agents with and without this security skill on two tasks:
Setup:
Results
Task 1:
|
| Model | Without Skill | With Skill | Δ | computed() pass rate |
|---|---|---|---|---|
| gpt-4o-mini | 80% | 100% | +20% | 0% → 100% |
| gpt-4o | 88% | 100% | +12% | 40% → 100% |
| gpt-5.6-sol 🧠 | 100% | 100% | 0% | 100% → 100% |
Task 2: fix-dom-manipulation
All 3 models score 100% with and without skill — this task is already well-understood by current LLMs, confirming the skill targets only patterns agents don't know.
Per-Check Breakdown
The check that differentiates: uses-computed. Without the skill, models use plain arrow functions or methods instead of Angular's computed() signal to memoize the sanitized value — causing unnecessary re-sanitization on every change detection cycle.
Key Finding
The skill lets
gpt-4o-mini(cheapest model) match the output quality ofgpt-5.6-sol(most expensive reasoning model). Without it, standard models consistently miss thecomputed()signal pattern — a best practice that only reasoning-tier models infer on their own.
The skill doesn't help where it's not needed (task 2 has 100% baseline), and it provides measurable lift exactly where agents struggle (task 1's DomPurify + computed pattern). Zero regression on any model.
Happy to run with more trials or different models if needed.
| @@ -0,0 +1,109 @@ | |||
| # Security and Sanitization | |||
There was a problem hiding this comment.
I think the title is too broad in general, and the file name is too; if we're talking about security, the topic is much broader.
Example
We could mention HTTP level vulnerabilities, SSR with SSRF, among others mentioned in
There was a problem hiding this comment.
An initial step could be to focus solely on general sanitization, as explained in the file.
There was a problem hiding this comment.
Good point, I agreed that 'security' is too broad a title for a file that only covers the sanitization pipeline. I've renamed the file to sanitization.md and updated the title to HTML Sanitization. I've also added a scope notice at the top of the file explicitly pointing readers to angular.dev/best-practices/security for HTTP-level vulnerabilities (CSRF, SSRF), CSP, authentication, and the rest of the Angular security model.
There was a problem hiding this comment.
Exactly the approach I took, the file is now scoped strictly to sanitization (the [innerHTML] pipeline, DomSanitizer, DOMPurify, and Trusted Types). The rename to sanitization.md and the updated scope notice make that boundary explicit.
554b134 to
a85ebc3
Compare
| private readonly sanitizer = inject(DomSanitizer); | ||
| readonly videoId = input.required<string>(); | ||
|
|
||
| // Use a computed signal to safely derive the resource URL |
There was a problem hiding this comment.
This is not correct, we could not guarantee it, I think we could rephrase it.
There was a problem hiding this comment.
Good catch! I've removed the word 'safely' from the comment to make it clear that the computed pattern itself does not guarantee safety, and added a reminder that the input must be strictly validated before bypassing security. Fixed and pushed.
a85ebc3 to
4ee9792
Compare
Co-authored-by: Jaime Burgos <73321943+SkyZeroZx@users.noreply.github.com>
| @@ -0,0 +1,111 @@ | |||
| # HTML Sanitization | |||
|
|
|||
| > **Scope**: This reference covers Angular's built-in HTML sanitization pipeline and patterns for rendering untrusted HTML safely. It does **not** cover the full Angular security model. | |||
There was a problem hiding this comment.
It does not cover the full Angular security model.
For HTTP-level vulnerabilities (CSRF, SSRF), authentication, Content Security Policy, and other security topics, refer to the Angular Security Guide.
I also wonder if this is necessary considering the file is called "sanitization" and we're primarily talking about HTML. I'm not sure if it will contribute much or not. Let's see what others say.
And it also feels somewhat repeated regarding SKILL.md that says
When rendering dynamic or untrusted HTML content, consult the sanitization reference. For the full Angular security model (CSRF, SSRF, HTTP-level vulnerabilities, CSP), refer to the Angular Security Guide.
Adds a new reference file for context-based sanitization, bypassing security with DomSanitizer, the Safe Pipe pattern, and Trusted Types to the developer skill.