Hi Viktor, Thank you very much for your proposal, and I’m sorry it took me so long to get back to you.
I understand the reasoning behind centralizing SQL parameter validation in a single interceptor for cleaner separation of concerns. However, the core issue isn’t just where we perform the validation - it’s that we are relying on native SQL queries with string concatenation in the first place. The better long-term solution is to avoid native queries wherever possible and instead use JPQL, the Criteria API, or repository methods. If native queries are truly necessary, they should be written using prepared statements to eliminate the risk of SQL injection entirely. This approach not only removes the need for extensive parameter validation logic but also aligns with best practices for both security and maintainability. Best regards, Adam > On 2025. Mar 31., at 14:27, Viktor Pavlenko > <viktor.pavle...@onix-systems.com.INVALID> wrote: > > All the time i see that we are using custom sql validation in many api > controllers where params there are sql value like (orderBy, sortBy and etc.) > and i have suggestion, if we want to continue use it, if remove all > sqlValidation from controllers and add interceptor which will be fetch from > URL all this params and validate there. What will have benefits in this way? > - (Just single responsibility), We'll have 1 class where we can handle all > their values without injecting the SqlValidation component to each api > controllers!
