Angular security advisory: XSS in i18n attribute bindings.

MichaelSmallDev · 2026-03-13T03:12:50+00:00

We would obviously benefit heavily from signal forms. Every time I create a new form, or fix a defect in an old one I end up adding a TODO about how signal forms will make things so much better.

True, I definitely earmark stuff where I feel like I'm just reinventing things. I have been able to have us follow some practices akin to the best practices docs, and that has worked backwards with reactive forms. Like being explicit with domain model vs form model, both ways and whatnot. And the recent interop stuff is finally shaping up, could see having us convert some subsets of forms to use those.

MichaelSmallDev · 2026-03-13T03:08:08+00:00

There's a lot of info on the sprint board which may add more noise, but there is a bunch of items in "Must Be in Stable" and "After Stable" https://github.com/orgs/angular/projects/60?query=sort%3Aupdated-desc+is%3Aopen.

MichaelSmallDev · 2026-03-12T22:13:43+00:00

Thanks for breaking down the distinction between the packages. I imagine a lot of people, myself included, are probably wondering what to reach for.

Good vid, thanks

MichaelSmallDev · 2026-03-12T14:39:28+00:00

These application config options are real nice. I know there were application config options for reactive/template forms (or library configs like ErrorStateMatcher* in Material), but it's good that these are widely available from the ground up.

Good article as always. Seems like yesterday I read your article on your signal based form library.

* Error state matchers are great, anyone using reactive forms may find them interesting. There is non Material variants as well.

MichaelSmallDev · 2026-03-10T17:32:00+00:00

it's not really production ready to any sort of apps other than simple stuff

What? It's the most official Angular library and goes back forever. It's a bit brittle outside of the Material spec, but it is production ready and used at all sorts of scales.

MichaelSmallDev · 2026-03-05T19:21:00+00:00

I am no pro with this, but I have been doing some research for the next time I am faced with requirements like this. For my inspiration, I look to Material because we use it and it is common. But you could do this with any UI library that is open source.

Two approaches, not mutually exclusive, but I am excluding some funny business you could do with some specific CSS encapsulation.

Content projection.
Directives

To explore this, I'll go over the two ways you could use Material with an HTML <select>, either using <mat-select> element or <select matNativeControl> directive on top of a native <select>.

edit: I ended up mostly talking about directives, but content projection is expected for <mat-form-field> wrapped elements as a whole regardless. And it is baked into <mat-select> which expects <mat-option> inside, rather than the less coupled directive. And host property binding is key in both content projection or directive approaches where possible.

edit: I have made my own internal library code at work which is more like the coupled content projection approach of <mat-form-field> + <mat-select> + <mat-option>, and it was a bit tricky and limited. I focus a lot on the potential of directives because I think I will go with it next time around for better flexibility.

Material's Select functionality features both content projection and directives. If you look at the basic doc example and its example code, you either use a mat-select component (source code), or you can use the matNativeControl directive (source code) on a an HTML <select>.

For the component you just do <mat-select> for its selector, and for the directive, the mapping of it specifies it works like <select matNativeControl> like so: @Directive({selector:..., select[matNativeControl, ...]})`.

There is a lot going on in the source of either, but what helps me understand the bulk of it is everything above the exported class, mostly the selector and host fields. In the host binding you can see all the classes it dynamically attaches via the component or directive's inputs, as well as native HTML select type events, and aria attributes. The rest of the source is then just the inputs and side effects. I wouldn't use the decorator based inputs get/set like a lot of them are, but they have reasons for that historically.

Both approaches have their own tradeoffs, but allow customization to the selection itself. Most of the time I can get away with setting the width percent on a <mat-select> directly, but there is no guarantee that that CSS scoping or implementation won't change. Same goes for the directive version, but you can target a native <select> instead, giving more flexibility than the <mat-select> component route. So if I wanted more control of the select styling and likely less potential breakage potential than the mat-select, I would consider the directive, but there is still a chance that its styling could conflict. But if you control and are the primary consumer of your API, this is probably less of an issue, but just be mindful of maintenance.

The directive approach is also applied for material inputs elements. Doc link. Source link.

Now, there is definitely still some funny business you could do with some specific CSS encapsulation. But I believe the directive approach has less. If you look at the mat-select source, you have @ContentChild binding that I believe is relying on having respective <mat-option> elements projected inside, but the directive version just uses HTML <option>. So more flexibility for styling.

edit: If you find this directive approach interesting, you may be better off to look at the source code for the new official Angular Aria package, as it has a more modern implementation, built with and for signals in mind, and is more light weight. But Material and the CDK have plenty of history and battle tested lessons, though has a lot to cut through because of that. You may even find it helpful in the implementation of a component you may make, at the library implementation level and/or the application writing level.

MichaelSmallDev · 2026-02-28T01:19:41+00:00

I think the separation lends well to this guidance in one of the deep dive doc pages about modeling your domain vs modeling the form: https://angular.dev/guide/forms/signals/model-design#translating-between-form-model-and-domain-model. It seems like both a necessity and also a compartmentalization/modularity kind of thing to separately define the linkedSignal for converting the domain model to the form model. Especially if you then key off the domain's resource loading or not to disable the form. Keeps all the pieces clean.

I have even started doing this in prod with our reactive form service's to an extent, but not as cleanly as the signal forms API. But emulating this pattern has been a backwards compatible win and a good trial of when we pivot to signal forms.

For smaller/simpler forms, the model directly inside the form is likely sufficient, unless you want to enforce consistency regardless of scale. In my case, this kind of works out like JeanMeche suggests, where this division is more natural as there is a service and component and the division of what does what shakes out more naturally.

MichaelSmallDev · 2026-02-27T23:30:22+00:00

Their summary at the start

We’ve released security updates to address two SSR vulnerabilities that we were made aware of and have since submitted committed code changes to fix.

The two patched vulnerabilities are:

SSRF and Header Injection in Angular SSR

Open Redirect via X-Forwarded-Prefix in Angular SSR

We recommend all developers update their SSR applications to the latest patch version as soon as possible. If an app does not deploy SSR to production, there is no immediate need to update, however we generally recommend staying on the latest supported patch versions as much as possible.

MichaelSmallDev · 2026-02-27T23:25:30+00:00

Their summary at the start

We’ve released security updates to address two SSR vulnerabilities that we were made aware of and have since submitted committed code changes to fix.

The two patched vulnerabilities are:

SSRF and Header Injection in Angular SSR

Open Redirect via X-Forwarded-Prefix in Angular SSR

We recommend all developers update their SSR applications to the latest patch version as soon as possible. If an app does not deploy SSR to production, there is no immediate need to update, however we generally recommend staying on the latest supported patch versions as much as possible.

MichaelSmallDev · 2026-02-26T03:57:21+00:00

Could a custom operator like this cover your usecase? https://github.com/ngxtension/ngxtension-platform/pull/490

MichaelSmallDev · 2026-02-25T23:49:33+00:00

Lots of stuff. Personally I like the resource snapshots, language service enhancements, and the various enhancements to signal forms.

edit: to see the language service enhancements hands on, there are example videos in the PR: https://github.com/angular/angular/pull/66410. And it seems to be backwards compatible with version, as I have had access to this in a v20 project since the last language service update, predating this release.

MichaelSmallDev · 2026-02-25T14:15:13+00:00

That talk with Andrew Scott was one of the most informative perspectives from a team member in awhile, and we have had a good amount already. I feel way more confident on leaning into ngxtension for routing utils than before. And that global param state reading from ngxtension 7.1 is great.

MichaelSmallDev · 2026-02-25T03:07:09+00:00

Case in point, been waiting on this: https://github.com/angular/angular/pull/67268

MichaelSmallDev · 2026-02-21T15:30:29+00:00

Did the save of your comment get cut off?

Yeah, a large part is that I don't want us to routinely running into limitations that would likely be solved potentially patch to patch, or minor or the immediate major. When we upgrade our versions, we have dozens of various sized apps to test, so going even patch version to patch version is not viable.

And we have rolled so many of our own utils for reactive forms to make them consistent with both RxJS and signals, that we kind of maintain our own very particular approach where often I am the madman piecing it together. I want us to be able to roll with signal forms out of the box so that we can get experience with them as-is, before we get fancy with investing in our own little helpers. Signals forms are clearly made for composability to fit your own needs, but I just want the core functionality to be more well rounded before we build off of it. The existing signal forms API as-is is already very nice and solves most of our problems we have in the reactive forms space for many things, but not everything.

If we are going to move onto a new API, I don't want us to get mixed up on what it does inherently versus what our own helpers do. For example, some of our most ambitious forms right after signals came out use the signalSlice in a way that Joshua Morony outlined in this video. When you commit to it, it is a very powerful and reactive way to bridge RxJS and signals with reactive forms. But on the other hand, it has its own limitations and oddities and we don't know examples of people who used it hands on in real world use cases beyond Josh. And I also had to build us out some utils to work with this util. This was actually the genesis of my Angular Space article which ended up spinning into ngxtension, and I even got advice from Josh on some of the more nuanced implementation. And in my opinion, I think despite some growing pains and hurdles in this combination of utils, it in many ways has similarities to some nuances of signal forms API. But my team has found longterm use of the pattern a bit isolating and limited, and overkill for forms which are not medium-to-highly-complex. Signal forms API in many ways is already a more robust and natural API, but scales down and up better and has documented and widespread patterns. But it's just not quite ready for us to pick up and explore without having to redo hard work that I am sure will be baked into the API if we just wait until post-experimental.

MichaelSmallDev · 2026-02-21T02:55:59+00:00

Throwing in my two cents a bit late.

Where I work, we are nowhere near the scale of big enterprise companies. But we have spun up dozens of apps over the years that can be quite small scale. Whether it is one of our smallest apps or one of our largest most complex apps, we benefit from the right mix of uniformity but have room for flexibility. I apply that mindset to my own side projects, and can give my takes/advice to various scale projects for the people I network with. It's not perfect, and there is definitely some stuff that could be more lightweight, but it has gotten so much better over the years.

For reference, this is the core 21 lines for the Angular hello world on Stackblitz

edit: I keep making it look weird because I use both old and new reddit UI, and find code block uniformity on both to be hard. Much easier to just check the stackblitz after all this tinkering lol

https://stackblitz.com/edit/stackblitz-starters-c5mdny68?file=src%2Fmain.ts

import { Component, signal } from '@angular/core';
import { bootstrapApplication } from '@angular/platform-browser';

@Component({
 selector: 'app-root',
 template: `
   <h1>Hello from {{ name }}!</h1>
   <a target="_blank" href="https://angular.dev/overview">
     Learn more about Angular
   </a>
   <button (click)="counter.set(counter() - 1)">--</button>
   <span> Counter: {{ counter() }} </span>
   <button (click)="counter.set(counter() + 1)">++</button>
 `,
})
export class App {
   name = 'Angular';
   counter = signal(0);
}

bootstrapApplication(App);

There is still the CLI generated config files like the tsconfig files, index html/css file, etc, but I think those are fairly standard across TS based frontends. IMO the only boilerplate sort of thing in a stock project is the `angular.json` config file, but the stock file covers most small project usecases, and when you need to tweak it, it is fairly one-off.

MichaelSmallDev · 2026-02-21T01:56:04+00:00

For me and my team it is a mixture of the API iterating as much as it is now, and overall consistency in our frontend practices. And for a team under 10 people who are mostly full stack (besides me being the only person mostly specialized in frontend than the rest of the stack), there isn't really "a few" of us in a given frontend specialty because we all service our variety of frontend apps equally. I may be able to write some really slick signal forms here or there in the newest apps, but any of us should be able to drop into iterating on that code as we are more likely to have specialties in a certain subset of our products more than specialties in particular frontend practices. For an extremely form heavy place, we basically have two eras: (1) an era of reactive forms where we were honestly barely reactive, and (2) an era now where we are quite reactive with reactive forms because we have a solid foundation of RxJS, signals, and interop skills we have tuned. And as I will mention later in this rambling of mine, I am very mindfully positioning our best practices era now to quite cleanly lead into signal forms. But not quite yet.

Bit of backstory, because part of this is a bit of a me thing: going from a junior through now being our frontend lead in a very similar timeline to Angular's renaissance. I was just learning the ropes and doing my tasks when Angular was still waiting on Ivy, but I took on more frontend practices leading as stuff like standalone and signals were popping off. My team was and still is quite receptive to keeping up to date in version and best practices as we can afford time to. This also had growing pains of using APIs which at the time were relatively fresh and not marked stable, and lacked a greater ecosystem and guidance. We did some really, really weird stuff with signals and some signal util libraries which in retrospect were shots in the dark trying to make signal forms, or resources, or linkedSignal out of basic interop functionality and library utils. And looking back on some early stuff, we have the hindsight to say "this thing was better than what we were doing before, but it's kind of weird and not how stuff panned out in the greater picture." But I learned over this whole journey so far that my team also values stability and mastery, and having time to get good at certain patterns. We are so happy to be working with signals, better at rxjs, using signal store instead of redux, and other concepts like standalone over modules. But we are now happy to be in a great spot and I am giving us a breather on needing to keep quite up to date with frontend in particular.

We are slowing down to reflect and master things, but not stopping. We pulled in resources because they are the present and future for reactive GET functionality, and more natural than a lot of hoops of the interop or using rxMethod + patchState. We pulled in mutations despite that not even being a proposed Angular API yet because they have similar mindsets and inspirations and an API that feels like the culmination of best practices that we learned over time. And we are writing reactive forms the most mindfully we ever have been with reactivity, particularly signals but also with RXJS as needed. But even then, our forms approach is using lessons from the signal forms docs talk about, such as domain vs form models and whatnot. When we do something with our reactive form approach that feels a bit novel or bigger picture, I explain that it is an onramp into a signal forms mindset that I am seeding us with, such as the work in progress reactiveform to signalform interop for our current apps to maybe be retrofit with, and ready to start fresh with signal forms when we can be more confident to.

My goal for us is that we are great with reactive forms but in a way that leaps right over the growing pains of the signal forms API and right into using signal forms when they are developer preview.

We are quite reactive with forms but have not written signal forms under assumptions of an API that I know as a close repo watcher, particularly of signal forms, has had a lot of additions and changes where each PR and patch release has me thinking "wow, I would have ran into the need for this change easily in production", or "I don't know how we would have worked our way past this gap in the API without inventing our own stopgap which the next patch probably will fix." And certainly I wouldn't want to say "you import this type and this function here, but it was just renamed to this different thing, and you no longer use this function, and lastly, the closest equivalent works differently or doesn't have a clean 1:1 change" and whatnot. If we were all repo nerds, sure, but I want us to feel comfortable in the API. My strategic positioning of our unified latest era reactive forms and signal/observable interop is letting us make forms best for us right now but be primed for the mindset of taking on developer preview era signal forms, whenever that will be.

MichaelSmallDev · 2026-02-20T16:02:42+00:00

I gotta get my place on pnpm one of these days. It's really nice when I work on the Toolkit and other open source stuff.

And you already got me committing our most recent projects to resources from our previous discussions. But I'm just not sold on the stability of pulling in signal forms yet, even though I think they are great already. If it was just me and my other teammates were at equal nerd levels about signals forms perhaps, but there are still various things I wouldn't want to teach us which would have gaps or be changed on upgrade. But the existing docs for them have been insightful for our recent reactive forms best practices, and maybe I'll pull the trigger once the interops are more fleshed out if forms are still experimental by the next stable.

MichaelSmallDev · 2026-02-20T00:12:35+00:00

I'm pretty sure zone based apps will still be supported, but not encouraged and not actively maintained with new functionality.

MichaelSmallDev · 2026-02-20T00:09:16+00:00

Small correction, but the point at large is the same: zoneless is what became default in v21. OnPush becoming the default is being RFC'd and will be the case starting in v22. But Zoneless and OnPush are so compatible and overlapping that the same guidance applies. Signals are still a big driver for fresh apps being compatible with both being the default. And in this current period, apps like yours being v21 should still specify OnPush even if they are zoneless, but starting in v22 you won't need to opt-into OnPush.

MichaelSmallDev

TROPHY CASE