Introduced DELETE=1 with granular per-endpoint delete controls

[Programmer-Admin]

What and Why?

Previously, enabling POST=1 allowed all write operations, not just literal HTTP POST calls.
This meant that destructive operations like DELETE were implicitly permitted whenever POST=1 was set — which was dangerous, since any malicious container/service could trigger deletes.

This change introduces:

A new global flag DELETE=1 to explicitly control delete operations.

Granular per-endpoint delete toggles:

• ALLOW_IMAGES_DELETE

• ALLOW_NETWORKS_DELETE

• ALLOW_CONTAINERS_DELETE

Now, a delete request is only allowed if:

1. DELETE=1 is set, and

2. the relevant per-endpoint delete flag is also enabled.

This ensures DELETE access cannot be accidentally granted by POST=1 anymore, closing the privilege escalation gap.

Next steps

If approved, this design will be extended to other sensitive endpoints (e.g. secrets, configs, etc.) to provide consistent, fine-grained access control.

[Programmer-Admin]

@josep-tecnativa , @pedrobaeza - Can anyone of you please review or suggest changes for the approach for this PR, once you get some time? Many thanks!

[Programmer-Admin]

@josep-tecnativa - Did you get a chance to look at this PR?

[josep-tecnativa]

Sorry for the late review, and thanks for this improvement — the change makes sense and looks good to me. From our side, we don’t need to adjust anything to keep our current setup working as usual. It would just be nice to update the README to reflect the new DELETE behavior.

[Semmu]

FYI there is a different PR implementing almost the same thing: #102