Is this package handling injection attack?

[hardiklakhalani]

Because the Query url get's exposed, Is this package handling a query injection attack? if so, more details will be helpful for the package consumers. Thank you.

[Tucker-Eric]

Because the Query url get's exposed
This is only true if you implement it that way. Some of the design decisions we made in developing the way data is sent to a filter and applied in that filter were:

• The filter method shouldn't have knowledge of a request to avoid tightly coupling a user generated request into to filter logic
  • The example User::filter($request->all())->get(); can just as well be User::filter(['name' => $request->query('name')])->get();
• Requiring explicit filter methods to be defined.
  • This avoids passing too much data to a filter and having it implicitly try to constrain by property names.

Is this package handling a query injection attack?
This package doesn't handle the query construction at the ORM level, it is a thin abstraction on top of Laravel's QueryBuilder which does sanitize input.

But, as with every other library, this package isn't immune to a developer bypassing any of the framework features to sanitize input and explicitly introduce sql injection into their own queries.