enhance/normalize EDITABLE_MITIGATED_DATA handling

[valentijnscholten]

Fixes #6078

I thought it would be nice to allow the Finding API to accept mitigated and mitigated_by values for super users and when settings.EDITABLE_MITIGATED_DATA was True.

This PR adds that. It also normalizes the check in all place.

Two notes:

• The Close Finding UI form did not allow setting these fields at all. Now it does if the setting is enabled and the user is a superuser.
• The Close Finding API allowed non-superusers to modify the mitigated timestamp field if the EDITABLE_MITIGATED_DATA was enabled. Not sure if this was intentional, but this PR now guards that field by the same central helper method. So only superusers can set if and EDITABLE_MITIGATED_DATA must be enabled. Is this oké?
• The Close Finding UI and API have this missing note types functionality. I don't fully understand it, but this PR now allows superusers to create findings that are mitigated and do not have any notes. Is this oké?

It looked like a simple change at first, but these inconsistencies made it hard to find out what is/was the intended behaviour. Do we want to allow creation and updating of findings as mitigated without doing the close finding api call?

Users can do this in the Edit Finding feature of the UI, so I think it should be supported in the API as well.

[dryrunsecurity]

This pull request exposes internal configuration details in API validation error messages by returning the flag name EDITABLE_MITIGATED_DATA=false in responses (reported in dojo/api_v2/serializers.py at two locations), which risks information disclosure that could aid attackers. Reviewers should remove or sanitize the flag from error messages to avoid leaking internal state.

Information Disclosure via Error Message in dojo/api_v2/serializers.py

Vulnerability	Information Disclosure via Error Message
Description	The application's API returns a validation error message that explicitly includes the name of an internal configuration flag, EDITABLE_MITIGATED_DATA=false. This exposes internal system details to the client, which can aid an attacker in understanding the application's configuration and internal logic.

django-DefectDojo/dojo/api_v2/serializers.py

Lines 1786 to 1789 in 5f86e14

	errors["mitigated"] = ["Editing mitigated timestamp is disabled (EDITABLE_MITIGATED_DATA=false)"]
	if ("mitigated_by" in data) and (data.get("mitigated_by") is not None):
	errors["mitigated_by"] = ["Editing mitigated_by is disabled (EDITABLE_MITIGATED_DATA=false)"]
	if errors:

Information Disclosure via Error Message in dojo/api_v2/serializers.py

Vulnerability	Information Disclosure via Error Message
Description	The application's API error messages explicitly reveal an internal configuration setting (EDITABLE_MITIGATED_DATA=false). This provides unnecessary internal system details to API consumers, which could aid an attacker in understanding the system's configuration and potentially inform further reconnaissance or exploitation efforts.

django-DefectDojo/dojo/api_v2/serializers.py

Lines 1940 to 1943 in 5f86e14

	errors["mitigated"] = ["Editing mitigated timestamp is disabled (EDITABLE_MITIGATED_DATA=false)"]
	if ("mitigated_by" in data) and (data.get("mitigated_by") is not None):
	errors["mitigated_by"] = ["Editing mitigated_by is disabled (EDITABLE_MITIGATED_DATA=false)"]
	if errors:

---

All finding details can be found in the DryRun Security Dashboard.

[Maffooch]

I think this is a fine approach - one tests as passing, I'll approve

[mtesauro]

Approved