Advanced search often leads to SQL injection. This is because there are some parts of SQL queries that can't be parameterized. If you allow the user to dynamically select which table to query against, or which columns to fetch, or how to sort or group the results, you need to sanitize all of these inputs by hand.

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.

In addition to SQL injection, many "advanced search" engines will compile regular expression patterns from user input. Depending on the language, this can range from a simple Regex DoS to Code Execution (I'm looking at you PHP).

Advanced search generally isn't.

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.

You let the user construct what feels like an SQL query, and many times it turns out that under the hood it is an SQL query, and it's not as trivial to paramaterize those queries.