I think what is being talked about are "Stored Procedures". Triggers are fired internally in the database when actions are performed, but stored procedures are direct parameterized functions.

Why are triggers (stored procedures) not often used to secure a database?

Sometimes laziness, sometimes it's just too restrictive. It's also the case that using parameterized SQL queries in your code also prevents SQL injection attacks. Jeff Atwood wrote a decent article about tradeoffs with stored procedures back in 2004.

That said, even with parameterized SQL queries, stored procedures still have a place in my mind, especially with passwords. There is no good reason for the application to ever query the password hash from the database system, only to ask the database system to compare an input value (such as a generated hash to keep the load off the DB server) against the hash. For that scenario, a stored procedure definitely adds security and I really wonder why nobody ever uses that.

Wouldn't that be much easier to make a trigger check for injection

Well, let's consider this: if your trigger can check for SQL injection, then I presume your code could as well. Then you either have a whitelist of values, or a blacklist for detection. Blacklists are poor choices. Even then, if you're doing whitelists the enumeration factor could be immense if you don't trust any of the query input at all, including the structure. Then we're back to either writing a stored procedure for every possible operation or using parameterized queries... and generally, the second method is saner.

I think what is being talked about are "Stored Procedures". Triggers are fired internally in the database when actions are performed, but stored procedures are direct parameterized functions.

Why are triggers (stored procedures) not often used to secure a database?

Sometimes laziness, sometimes it's just too restrictive. It's also the case that using parameterized SQL queries in your code also prevents SQL injection attacks. Jeff Atwood wrote a decent article about tradeoffs with stored procedures back in 2004.

That said, even with parameterized SQL queries, stored procedures still have a place in my mind, especially with passwords. There is no good reason for the application to ever query the password hash from the database system, only to ask the database system to compare an input value (such as a generated hash to keep the load off the DB server) against the hash. For that scenario, a stored procedure definitely adds security and I really wonder why nobody ever uses that.

Wouldn't that be much easier to make a trigger check for injection

Well, let's consider this: if your trigger can check for SQL injection, then I presume your code could as well. Then you either have a whitelist of values, or a blacklist for detection. Blacklists are poor choices. Even then, if you're doing whitelists the enumeration factor could be immense if you don't trust any of the query input at all, including the structure. Then we're back to either writing a stored procedure for every possible operation or using parameterized queries... and generally, the second method is saner.