The answer is definitively "yes", "no" and "it depends". The better way to ask this question would be "Knowing I have limited resources, how should I prioritize a review of my web-application?".
In security, success isn't defined as being 100% secure. Success should be defined as reducing risk down to an acceptable level. Your "acceptable level of risk" should be based on what your application does, what it protects, what's the fallout if something bad happens. I want more review done of the code that runs my pacemaker than I do of the Android game I buy for a dollar.
For 99% of organizations, resources are limited. It's unlikely that you will have the resources to throughly test every aspect of your web-application. You have to understand what resources you have available for review and then prioritize.
Every application is different so you should make your own judgements but here are some things I would prioritize:
Inputs that are used as part of SQL queries (SQL injection)
Inputs that are used as part of executed commands (command injection)
Inputs that are used as part of LDAP queries (ldap injection)
Inputs from one user that are echoed back to other users (persistent XSS)
Inputs from one user that are echoed back to that user (reflected XSS)
Inputs that are used as part of actions that modify a user's account
Inputs that are used as part of any complex processing (resource exhaustion DOS)
Inputs that are passed on to any processes that run with elevated privileges
Additionally, knowing that you can't exhaustively review every aspect of your web-app, you "cheat" by adding in additional mitigations:
Run your web-server without elevated privileges
Accounts for DB access should have minimal privileges
Have separate accounts for different types of DB access. If 95% of your DB calls are read-only, don't use an account with write privileges for those.