Where Next.js's server-first model changes what you need to defend against.
Server Components genuinely help by default here: code and data that never gets sent to the client — API keys, database queries, internal logic — simply isn't part of the client bundle at all, which is a meaningfully stronger default than a traditional SPA, where anything referenced in client-side code is visible in the shipped JavaScript. That protection has an edge worth knowing, though: props passed from a Server Component into a Client Component do get serialized and sent to the browser, so accidentally passing a sensitive object through that boundary is a real, easy mistake.
Server Actions need the same input validation and authorization checks a traditional API endpoint would — a Server Action is effectively a public endpoint the client can call, so it shouldn't trust its own arguments any more than a REST API trusts an incoming request body. Standard web security practices still apply in full on top of this: Content Security Policy headers (often set via Middleware), sanitizing user-generated content before rendering it, and being precise with environment variables — only variables explicitly prefixed with NEXT_PUBLIC_ are meant to reach the client, and treating that prefix casually is a common way secrets end up leaked.
What you'll walk away knowing