Nest: Add `X-Powered-By: NestJS` to the response header information by default

[BrunnerLivio]

Feature Request

Is your feature request related to a problem? Please describe.

Most backend frameworks store the information with which technology the site has been built with the response header.
You can see examples of other technologies using this header in the app.json of Wappalyzer and search for "X-Powered-By"

Once we have implemented this, tools like Wappalyzer then can use this information to determine how the site has been built.

Describe the solution you'd like

By default, every application built with NestJS should have this information.

Teachability, Documentation, Adoption, Migration Strategy

This will override the X-Powered-By: Express information. Though I don't think we should consider this as breaking change since very very few applications could be affected by this change

What is the motivation / use case for changing the behavior?

• Traceability
• Promotion

[getspooky]

@BrunnerLivio Nestjs documentation includes a chapter called security so you can use helmet library to disable headers like Helmet
Nestjs Security

[jmcdo29]

@getspooky you're right that it does, but I agree with Livio that it would be nice for both promotion and traceability purposes to change the X-Powered-By header to get Nest's name out there more. If someone uses helmet to get rid of the header, then great it's give, but if not it says it's from NestJS. Just like it is in Express

[kamilmysliwiec]

Is there any other reason we should consider adding this except for promotion purposes? X-Powered-By should be hidden for security reasons anyway.

Also, adding a global middleware may slightly affect the overall performance + lead to some unexpected issues in edge case scenarios (e.g., when one passes the existing express instance to the ExpressAdapter).

I'm personally against this change since it doesn't bring any benefit to the framework users.

[BrunnerLivio]

@kamilmysliwiec its mainly for promotional/traceability purposes. The motivation behind this change is mainly that we can rely on #1006 to get the information on who is actually usinf NestJS. This change would help us with finding new projects which have been built with Nest. Many frameworks and technologies are already doing that, so I don’t think its an inheritely bad idea.

I think the edge cases & performance aspects can be covered with a more lightweight implementation, without using the NestJS middleware and rather configuring the underlying express or fastify instance.

Though I am alright if you don’t want to introduce this change.

[kamilmysliwiec]

I think the edge cases & performance aspects can be covered with a more lightweight implementation, without using the NestJS middleware and rather configuring the underlying express or fastify instance.

This sounds good as long as there are no performance-related consequences

[BrunnerLivio]

@kamilmysliwiec I just wanted to get back to my proposal & improve the performance aspect of my exiting performance. Though it seems like this proposal is not well received by the community, according to the likes/dislikes on your comment & issue.
Should I proceed with it?

[kamilmysliwiec]

Yeah, you're right. Let's drop this idea then!