The problem is that there are plenty of fields where your attempts at filtering will break user expectations horribly if you filter the data even remotely strictly enough to ensure security.
Such as, say, comment fields. It'd be terribly restrictive for your users if they can't write about <script> tags on a technical forum without munging it.
And you're still not safe. All the characters needed for an SQL injection attack, for example, commonly occur in normal English usage. All the characters needed for XSS commonly occur too, so you'd need more restrictive filtering.
And have fun when a bug that causes your filter to be more restrictive than it should now means data is unretrievable because you've just stored the sanitised output of your buggy filter.
Once you've dealt with that, you're still facing the issue of changing filtering requirements: What is safe for HTML may not be safe for your CSV export. What is safe for your PDF generation may not be safe for your HTML generation, and vice versa. Suddenly you're asked to pass data via an API, with different expectations of what a "safe" value contains. Boom.
In other words, if you believe that what is in your database is safe from causing security problems, you've lost. You need to treat every piece of data that may possibly contain user input as a potential cause of problems whenever you output it or pass it on anywhere, whether or not you've (attempted) to validate and restrict the input.
A typical example I used to have to deal with: Mail systems. HTML that is entirely safe when downloaded and rendered by a mail client that contains the HTML in a document that is just for that one e-mail, can leak data all over the place and compromise the users account if left unfiltered when rendered on the web server. You can't insert it pre-filtered into the database without inserting the raw content too because the user may want to download it.
And because the only reasonably safe filtering method is white-listing tags and CSS due to evolving standards, you will regularly have to revise the filters and add functionality and people will be very annoyed if their e-mails still don't render correctly after you've fixed the bugs (and if you have to tighten the filters again, you don't want to have to re-filter all the data).
Such as, say, comment fields. It'd be terribly restrictive for your users if they can't write about <script> tags on a technical forum without munging it.
And you're still not safe. All the characters needed for an SQL injection attack, for example, commonly occur in normal English usage. All the characters needed for XSS commonly occur too, so you'd need more restrictive filtering.
And have fun when a bug that causes your filter to be more restrictive than it should now means data is unretrievable because you've just stored the sanitised output of your buggy filter.
Once you've dealt with that, you're still facing the issue of changing filtering requirements: What is safe for HTML may not be safe for your CSV export. What is safe for your PDF generation may not be safe for your HTML generation, and vice versa. Suddenly you're asked to pass data via an API, with different expectations of what a "safe" value contains. Boom.
In other words, if you believe that what is in your database is safe from causing security problems, you've lost. You need to treat every piece of data that may possibly contain user input as a potential cause of problems whenever you output it or pass it on anywhere, whether or not you've (attempted) to validate and restrict the input.
A typical example I used to have to deal with: Mail systems. HTML that is entirely safe when downloaded and rendered by a mail client that contains the HTML in a document that is just for that one e-mail, can leak data all over the place and compromise the users account if left unfiltered when rendered on the web server. You can't insert it pre-filtered into the database without inserting the raw content too because the user may want to download it.
And because the only reasonably safe filtering method is white-listing tags and CSS due to evolving standards, you will regularly have to revise the filters and add functionality and people will be very annoyed if their e-mails still don't render correctly after you've fixed the bugs (and if you have to tighten the filters again, you don't want to have to re-filter all the data).