Should security parameters be explicitly set to default values?

AI suggests to still set the parameter values explicitly

That's a good advice.

Because defaults are for an average Joe. And you're not an average Joe.

Say a reverse proxy has a default setting for a size of the request. In Nginx, for instance, it's 1 MB. Is it a good choice? Well, it depends.

If you host a service where photographers would upload their photos, chances are, they would quickly stop using your service, as they won't be able to upload most of their files. The limit of 1 MB is too low and should possibly be increased to 20 – 50 MB.

If, on the other hand, you host a service that sends weather forecast on request, the limit of 1 MB is too high—1 KB limit would probably be more appropriate here.

Why would security sensitive or otherwise important parameters be explicitly set to default values?

Well, having to set everything makes it difficult to adopt a technology. You definitively don't want to have to specify dozens or hundreds of parameters when starting to play with Nginx for the first time. If you're forced to do it, you'll either abandon the thing and move to a competitor which is easier to adopt, or you'll ask your AI assistant to generate the “default” configuration file for you—or grab one from the internet. This is by no means any better than just having it inside the software product from the start.

Not having any limit for the size of the request is not good either: you don't want a naive user who didn't take time to configure his reverse proxy to find himself in a situation where an attacker—or a legit but slightly misconfigured app—starts making 10 GB requests.

So a default value is set, for people who are yet unfamiliar with the technology, and who just want to play with it.

In essence:

• If you want to discover a new software product, use it in your personal project, and see how it works, defaults are great. You don't need to think about them, until they start causing trouble (as a rather limited request size in Nginx often does).

• If you're experienced with the technology and are setting a production server, defaults are not what you want to use. Chances are, you know what all the values mean and can configure them for your particular case.

I think the answer here is "How much do you care?"

If you are spinning up a new site and aren't worried about DDOS attacks etc. You wouldn't be looking at these settings, and they have to be set to something, so you need a default.

If you are "working on hardening my service against Denial of Service (DoS)... attacks". Then you very much care what these settings are and want them set to tested values you know wont cause issues.

The default might be the same as the value you want to set it at, but defaults can change with updates and you very much care that this setting is set to the specific value that you tested. Not something else.

You reviewed the technology/framework/tools and identified desired values for certain configuration parameters.

You found that, by chance, those parameters are already set by default to equal or similar values. You also consider that those defaults where chosen with careful deliberation. You want to benefit from those values being revised when/if technology changes.

Chose either? There is a middle ground:

Leave parameters to defaults, and static assert that those parameters have the values you approved of. You can add documentation there explaining your choices. Then the compiler will notify you when those defaults change, and you need to review them. If static assert is not possible because those values are dynamic, configuration-dependent, etc. then log, assert, and have tests for that.

If you've come up with a value for the setting that is appropriate to your use case, you probably should set it - even if it happens to be the same as the default value. Explicit is better than implicit, and you may want to document how you came up with the value and how it applies in your situation.

If you were just looking at the setting, saw the default value, and thought "that looks sensible, let's use it", you probably will not need to explicitly set it. Except when you fear that these defaults may change, which brings us to:

[When setting the value explicitly,] I would not get benefit from updates when framework evolves

… but you would also be spared from the downsides that updates may bring. It basically comes down how you handle updates to that framework. Do you trust the framework developers enough to always come up with sensible default values, and to never loosen the security requirements? For example, the average costs per request are decreasing, so an estimation of the sensible request limits for a "normal application" may be higher ten years from now.

Of course, if you just never update your application and its dependencies, it doesn't make a difference whether you set the parameter or not. But if you are updating regularly (and of course you should!), you will always need do a security assessment in the process. How does your typical update workflow look, would it take care of the parameter being affected - and what risks are you willing to take?

This is easier to decide when the framework developers are transparent about how they treat these security-related settings and their default values - do they promise not to make breaking changes, do they regularly document changes to them in their release notes, do they implement deprecation warnings? How do they handle features becoming legacy, how does the framework treat outdated configuration? Not setting a parameter means "I don't care strongly about this, I trust the framework to (keep) behaving sensibly", whereas explicitly setting a parameter does express "I did check this setting and the current value is reasonable for our use case, if something in the framework changes we should re-assess it".

I want to touch on an aspect that I haven't seen be covered in the existing answers that I believe is more directly related to your question.

For starters, I agree with the other answers that, by the time you get to the point where you are tuning your service to be resilient to these kinds of security concerns, you shouldn't be depending on implicit default values. An important thing to understand about defaults is that they aren't generally defined by best practices, largely because what the "best practices" are will depend on the use case. Most of the time, they are designed for either what will work for the most common use case, or they are designed to provide the easiest configuration to get someone up and running. By this point in your development, however, you should have a good understanding on your domain requirements, and there's a good chance that the values you should use would match neither the most common nor most convenient use case.

That being said, you did mention that the framework you are using:

(...) has some sensible defaults in-place.

It can certainly be the case that the values you arrive at could be same as the default values. You should explicitly set the values anyway.

The reason why is because you aren't creating a lightweight and flexible service anymore. You are creating a service that needs to be resilient, and part of that resiliency comes from predictability. If Microsoft pushed an update to ASP.NET tomorrow that changed a lot of the default values, most likely one of two things will happen - it will either break everything in your service overnight, or it will go unnoticed for months. Which of those outcomes being worse can depend on who you ask, but suffice it to say that neither of them are desirable.

To illustrate this point, I want to highlight an assumption you have made:

I would not get benefit from updates when framework evolves, and do not have any proven benefits for this or any other particular limit.

Like I said before, the default values for the framework are almost certainly not defined by any metric that resembles best practices, and an update causing those values to quietly change on you is far more likely to cause problems than to yield benefits. You never want your configuration for your service to change without your knowledge or input because doing so is a recipe for all sorts of bugs and vulnerabilities to start quietly popping up.

Imagine if the update I mentioned earlier included a change that increased the default max payload size by a factor of 1000. You could be suddenly accepting gigabytes of data through an API that you created with the now-erroneous understanding that it would only be accepting megabytes. Not only could this cause your thoughput and/or storage costs to skyrocket, it could introduce an attack vector where perfectly valid connections can now start flooding your service with data, ironically enabling the exact DoS scenario you are deliberately trying to protect against.

And another point in the favor of explicitly setting the values of configuration options is that you ensure that you or whoever is maintaining the project after you will always know what those values are. Using default values means at some point you or whoever inherits your code will have to dig into the documentation to learn or remind yourself what those values are. This is already inconvenient, but it can become a huge pain when fielding questions by customers or auditors about how your service is configured - not only are they not going to accept "whatever is the ASP.NET default" as an answer, just the knowledge that you have left your service without an explicit configuration could by itself raise warning flags.