This makes no sense.

Thanks for taking a look.

To clarify the intent of this change: the issue is not field creation but field execution.

SQL custom fields already restrict creation to Super Users via
onContentBeforeSave, but the SQL query itself is executed later during
onCustomFieldsPrepareField when content is rendered. That execution path
previously had no authorization check, meaning any visitor viewing the
content would trigger the query.

This PR simply ensures that the same permission (core.admin on the root
asset) required to create an SQL field is also required at runtime when the
query is executed.

Without this, a SQL field created by a Super User can execute arbitrary
queries in an unauthenticated frontend context, which is an authorization
bypass (creation-time vs execution-time TOCTOU gap).

The change is intentionally minimal and localized to the SQL field template,
and does not alter field creation, storage, or non-SQL field behavior.

Because the SQL field plugin itself already enforces that restriction.

In plugins/fields/sql/src/Extension/SQL.php, the plugin checks for core.admin during onContentBeforeSave and explicitly blocks SQL field creation if the user is not a Super User. So the assumption is not theoretical or based on documentation — it is enforced in code today.

What was missing was the same authorization check at execution time. The SQL query stored in the field parameters was executed during rendering (tmpl/sql.php) without re-checking permissions, including in frontend and unauthenticated contexts.

So this change does not introduce a new restriction or opinionated policy. It simply makes execution-time behavior consistent with the creation-time restriction that already exists in the plugin.

that makes the field useless and it will never be rendered to an unauthenticated user. I think you dont understand what this custom field is for

I understand the intended purpose of the SQL custom field, and I agree that it can be used to expose selected data on the frontend.

The concern here is not about whether SQL fields can be used for frontend display, but about how Joomla already defines the trust boundary for this feature. The plugin itself treats arbitrary SQL as a Super User–level capability by enforcing core.admin at creation time. That establishes a clear security assumption in the codebase: defining SQL is privileged.

What was happening before this change is that a privileged configuration (the SQL query) was later executed in an unprivileged context without revalidation. That means the effective permission of the query changed depending on when it was used, not who was using it.

The patch doesn’t redefine the feature or make it useless — it makes execution match the same trust model that already exists at configuration time. If the goal is to expose public data safely, that’s better handled through components or queries designed for frontend access, rather than executing raw SQL defined under Super User privileges in an anonymous request.

My intention here is not to change the feature’s purpose, but to ensure the privilege boundary remains intact at both creation and execution time.

Sorry but you really don't understand

Not what the field is about, looks anyways like automated AI. Closing.

Beside that this is AI Slop, if you report a security finding, please always contact the security team first see https://github.com/joomla/joomla-cms?tab=security-ov-file#readme