Data is validated after the denormalization phase. To avoid type errors you can disable type checking in the normalizers.

I understand. However I was aiming more into a security kind of checking.
For an example I would like to prevent malicious javascript data from even reaching a validation phase and deserialization to an entity.

I've come up with a simple implementation by decorating a default decoder and manually inspecting string values from a raw JSON payload and throwing HTTP 400 if funky business was detected. It's a bit defensive I know so i was wondering about alternatives.

1. Always use parameterized (database) queries.
2. Always escape (for the correct context) untrusted data (anything that came from user input) on the client.

Hi, thanks for input.
You are absolutely right, but how do you suggest to accomplish 2nd rule if you are using a default api POST endpoint configuration without custom controller or any custom listener and only default constraint validators on entity (no fancy custom filtering).
If you send a HTTP POST payload with malicious XSS it will be persisted to database. It means it will go through ReadListener -> DeserializeListener -> ValidationListener -> WriteListener and end up in database.

If a string containing javascript is stored in the database, it’s not harmful per se. You shouldnt evaluate the javascript on output though.

Of course, that might be the solution. However, by using a default ApiPlatform implementation the XSS content will be returned to client. So you'll have to tweak around that.
Concerning security in general, a proper course of action should be to prevent any malicious data from entering into persisting layer. Better safe than sorry :)