TYPO3 Core

Patch set 2 for branch main of project Packages/TYPO3.CMS has been pushed to the review server.
It is available at https://review.typo3.org/c/Packages/TYPO3.CMS/+/88543

Patch set 3 for branch main of project Packages/TYPO3.CMS has been pushed to the review server.
It is available at https://review.typo3.org/c/Packages/TYPO3.CMS/+/88543

Here are the reasons, why I think the proposed approach (HMAC) is deceptive:

• Protecting __identity only, leaves all cases where the PersistentObjectConverter converts an object from a string/int unprotected
• HMAC is a fixed value and it is always publicly exposed (that is how it is designed). Once it is leaked, it can be reused an unlimited amount of times.
• HAMC conceptually is not enough to protect from "Broken Object Level Authorization (BOLA)", exactly because of the reasons above. Therefore such change will not allow developers to skip the check for object access permissions

In sum: it is deceptive, because it actually does make manipulation less accessible on the one hand, but still leaves the door wide open for multiple other attack vectors, which can not be fixed with the concept of using a HMAC

Thanks for your feedback!

I totally agree that this change does not resolve the underlying requirement for extension developers to implement proper access checks for actions like show, edit, update, or delete — especially in applications with authenticated users and varying access permissions. Ensuring authorization at the application level remains essential and cannot be "solved" by this patch.

The primary goal of this patch is to prevent manipulation of the hidden __identity field in forms generated via f:form and similar ViewHelpers. By signing the field value with a HMAC, we can make sure that it cannot be arbitrarily changed to another UID without triggering an exception during property mapping. This hardens a common attack vector where attackers could manipulate the UID in the hidden field and cause unintended data modification — assuming a missing or incomplete access check on the application side.

To address your concern: yes, the HMAC is publicly visible and not a secret per se—but it is tied to the specific object, meaning the HMAC cannot be reused for different object identifiers.

This change should be seen as a hardening measure to close one of the more trivial manipulation possibilities. It is not a general protection against IDOR and it doesn't replace access checks in any way. But it does raise the bar for attackers and helps mitigate accidental misconfigurations in custom access check implementations.