Unless you do something extremely silly with the login page, like sending it as a GET parameter, or storing it locally, or not having a CSRF token, or not using HTTPS, I don't see what special measures are required!
Sensitive data is not restricted to logins. If you are pulling in third party JS like for analytics, tracking, social, whatever then that is an attack vector. Marketing and business teams aren't responsible for security but they have the muscle to pull in dangerous code to the frontend that can be swapped out. It is naive to think that the API is the only thing to focus on.
The likelihood of a vulnerability in serverside logic is far higher and more impactful than a large marketing player like google analytics stealing PII.
If POST content type is application/json and is enforced, csrf is not possible. You cannot csrf put and delete unless you modify cors policies, all of which are server side vulnerabilities and not related to you using SPA vs server side rendering.
You can import malicious client side plugins irrespective of if it’s an SPA or server rendered. I’d much rather a silly plug-in be limited to client side JavaScript (which is sandboxed) over server side logic, which is not.
If users type passwords, sensitive data, anything into the frontend then any javascript, plugins etc pulled in by that page is an attack vector.