Would you use getServerSideProps or getStaticProps for private user data?

WHAT THIS TESTS: This question tests your understanding of the Pages Router data fetching lifecycle and its security implications. Specifically, the interviewer wants to know if you recognize that getStaticProps runs at build time and generates shared static artifacts, while getServerSideProps runs on the server per request with access to the incoming request context. The core concept is that private user data must never be baked into static files that can be served to other users or cached by edge networks.

A GOOD ANSWER COVERS: Four things in order. First, choose getServerSideProps because it executes on every request and receives the request object, allowing you to read authentication cookies or bearer tokens and return user-specific payloads. Second, explain that getStaticProps is unsuitable because it runs during build and generates HTML and JSON that are identical for every visitor, meaning one user's private data would become a public static asset. Third, mention that static files are often cached by CDNs and distributed globally, so even without malicious intent the data would be exposed far beyond the intended user. Fourth, note that getServerSideProps keeps the data fetch server-side so the client never sees tokens or internal API endpoints, reducing the attack surface.

COMMON WRONG ANSWERS: Suggesting that incremental static regeneration or revalidation makes getStaticProps safe for private data. This is incorrect because ISR still produces static output that is shared across all requests until the next revalidation. Another red flag is saying you can use getStaticProps and then filter the data client side, which ships the private payload to the browser. Some candidates also suggest making an authenticated API call inside getStaticProps, but build-time processes lack user session context and would fail or return the wrong user's data.

LIKELY FOLLOW-UPS: The interviewer may ask how you would handle this in the App Router, where you use async server components or route handlers instead of getServerSideProps. They might also ask how to pass the auth token from getServerSideProps to an internal API without exposing it to the client, or how to handle caching headers for authenticated pages.

ONE CONCRETE EXAMPLE: Imagine a dashboard showing a user's bank balance. If you use getStaticProps, Next.js generates a static HTML file with the balance at build time. That file is placed in the CDN and served to every visitor. If you use getServerSideProps, the server reads the session cookie from the incoming request, calls the internal banking API, and returns the balance only for that authenticated user, generating fresh HTML per request that is not cached publicly.