To prevent XSS attacks you should use a multi-faceted approach.
Does escaping quotes in a HTML attribute context prevent XSS?
Let's use the term "contextual output encoding" instead of escaping as part of this conversation.
"HTML Escaping" means you are taking "data" which may be interpreted by the browser as "control / instructions" and ensuring that it will only be treated as data.
Moreover, escaping/encoding should be applied as close to consumption by the client as possible. While you are processing the data you may need the "raw" data and you may need to send the same input data to multiple output contexts.
In your example the
As a side note, beyond XSS injection, an attacker may be able to just insert HTML or additional attributes which may have unintended/malicious impacts in your app. E.g., beyond XSS, if an attacker could add a regular
<a /> link on your page that could be used to redirect the user to a malicious page. in this case, if an attacker can "break out" of the attribute (go beyond the final quote/double quotes) it is another opportunity to add in attacker controlled "instructions".
In addition to output encoding, you should also perform input validation. Input validation is a go/no go decision on whether you should take in data in the first place. It is based on a combination of business and security rules. For example, if you have some field in your app "projectid" and it is defined as a non-zero integer, you should never allow this value to be a string or decimal value. This is breaking the expected convention and you should stop processing and throw and error/exception. After validation, you may also want to apply sanitization, which is where you clean up data and remove/replace values that you do not want present before the processing. For example, if you are processing data for HTTP headers, you will want to replace line-break and special characters like backspace which could be improperly processed.
Lastly, you will also want to implement Content Security Policy. CSP helps to restrict what code is allowed to run based on things like location, integrity hash, etc. CSP is very useful, but not that often you can't use is as a "silver-bullet" because you may need to use scripts that change without notice / outside your control like third party traffic analytics scripts. To learn more about CSP, start with this documentation on MDN.
You should be using a combination of these techniques to mitigate XSS.
For a good starting point, you can also check out the OWASP XSS Cheat Sheet.
To get more depth on contextual encoding, check out this video by Jim Manico starting ~7:00