With 7., doe you object that generally or do you find the implementations being faulty? In heterogeneous corporation environments, this is on the very top of the wish list, if not number one.
With 7., doe you object that generally or do you find the implementations being faulty? In heterogeneous corporation environments, this is on the very top of the wish list, if not number one.
This is why saying "it's easy, just parameterize your queries" is bad advice. It's incomplete. There are still these unfortunate holes in most stacks that require you to be careful and whitelist user inputs.
It usually comes down to either searching the search terms for specific keywords, or tokenizing the search terms. The keywords are then treated as special, and may be used against different backend stores or with different pieces of logic.
What this means is that a simple search has a single well-defined execution path... and simpler code is easier to check for attack vectors and to harden.
Advanced search introduces many execution paths, possibly facing different tech, and is likely to have multiplied the attack surface whilst making it hard for a developer to spot all of the attack vectors.
Other problems arise from this: If you pre-process the search terms to clean the input, it may be that a later step in your "advanced" query transforms the search terms in a way that makes an attack possible.
Basically: Keep It Simple Stupid rules when it comes to security and advanced search not implemented by someone mindful of security will probably knock big holes in whatever security you think you have.