Introduction and Critical Points
Defending against security threats, such as XSS (Cross-Site Scripting) and CSRF (Cross-Site Request Forgery) attacks is, like most of computer security, a case of defence-in-depth: there is no "one single approach" that defends against them. You need to use several different methods together to prevent them as effectively as possible.
First, however, some very important points about how you should go about this (and security in general).
1. Make sure you understand important security concepts
When using a framework, identifying what your framework does and doesn't have protection built in for, the significance of security threats, and so forth is rather difficult if you are not well familiarised with security concepts. Therefore, make sure you are familiar with them or learn them, because otherwise you will not be in a position to actually know if your website is properly secured or not.
OWASP (the Open Worldwide Application Security Project) website, and its cheatsheets, are fantastic resources for this purpose. You can find them here: https://owasp.org/ . They also have very useful references for how to use specific frameworks' protection features.
2. Know what built-in protections your framework has
Modern web frameworks (e.g. Django, Ruby on Rails, etc) often have some amount of XSS and CSRF protection built into them, alongside some other protections.
When a framework has protection features built in - use them. Frameworks are highly maintained, including by security experts, and so such protections are well designed and reliable. In addition, frameworks are updated over time, meaning that so long as you update your framework, new threats and attack vectors will be defended against as well by the framework, to the extent a framework is capable of protecting against them on its own.
3. Know what your framework doesn't protect you from
Relying on a framework to "solve all security problems" is bad. It's not possible for them to do everything, and you need to make sure you know which approaches it doesn't guard against so you can deal with those yourself.
4. Don't even consider rolling your own solution to any security problem unless you are insane
While with some security vulnerabilities there are standard approaches, and things you will have to manually do, the point stands: when it comes to systematic protections like anti-CSRF protection, password encryption and so forth: considering your own solution is normally an indication of severe insanity.
I am insane, and thus implemented CSRF tokens manually for Deserted Chateau because I didn't find any PHP frameworks I considered good for this purpose when I initially began making Deserted Chateau, but it is absolutely not a good idea and you should not do that. Even security experts don't do this, because they know they are more likely to make a mistake and not realise it than a framework designed and maintained by many people. Even then, I followed OWASP's guides on doing this, made sure the tokens were generated with cryptographically secure values, that no page is without them, and a bunch of other things that are a huge hassle and better dealt with by a framework.
Even in my case, where it remains a very bad example, it means I have had to take a lot of extra time making absolutely sure of various security details, and that I'll have to continually be viligant of new security threats in future.
5. Make sure to update your framework regularly
Updating is one of those things people, and developers, love to leave until later: software devs often worry a new update might break something, so they don't update, and then as time goes on, the larger number of changes between the current and new versions of their framework makes them even less likely to update.
Much of a framework's usefulness in defending against security threats is knowing how to enable the features it has, and making sure those features are up to date. A framework isn't too useful if it's way out of date and not protecting against a bunch of newer security threats. Relying on a framework when you don't know what it's doing, and haven't updated it, is a serious problem - because it gives the false impression of protection, meaning the unaware user thinks no action is needed. This is a major cause of many security breaches.