🔐 SameSite와 쿠키, 우리는 얼마나 알고 쓸까?

"쿠키를 어떻게 쓰고 계신가요?"

이 질문에 당당하게 설명할 수 있는 사람은 생각보다 많지 않습니다. 웹 개발을 하다 보면 무심코 cookie, sameSite, httpOnly, secure 등의 옵션을 설정하지만, 왜 그렇게 해야 하는지, 또는 어떤 의미를 지니는지 깊이 고민해본 적은 드뭅니다.

이번 글에서는 쿠키의 동작 원리와 함께 SameSite 속성의 의미, 그리고 이를 둘러싼 보안 이슈까지 짚어보려 합니다.

🍪 쿠키는 왜 사용할까?

쿠키(Cookie)는 웹 서버와 브라우저가 상태 정보를 유지하기 위해 사용합니다.

대표적인 활용 사례는 다음과 같습니다:

사용자의 로그인 상태 유지

유저 식별 및 개인화

API 인증 정보 저장 (특히 세션 기반 인증 시스템에서)

🕸 내 웹사이트에서 설정한 쿠키, 다른 도메인에서도 쓰일까?

대답은 **"예"**입니다.

조건만 맞는다면, A 도메인에서 설정된 쿠키는 B 도메인에서 A 도메인으로 요청을 보낼 때 함께 전달될 수 있습니다.

예를 들어:

사용자가 A.com에서 로그인하고 access_token 쿠키가 생성됨

악의적인 B.com에서 <form action="https://A.com/api/send-money" method="POST"> 같은 요청을 사용자 몰래 실행

이때 A.com에서 설정한 쿠키는 자동으로 포함되어 요청이 전송됨

결과적으로 사용자의 의지와 상관없이 민감한 동작이 실행될 수 있음

이것이 바로 CSRF (Cross Site Request Forgery) 공격입니다.

🧱 SameSite 정책의 등장

이러한 보안 위협을 막기 위해 등장한 것이 SameSite 쿠키 정책입니다. 이 정책은 브라우저가 쿠키를 언제 전송할 수 있는지를 제어합니다.

SameSite 정책 종류

값	설명
`Strict`	자신의 사이트에서 발생한 요청에만 쿠키 전송. 외부 링크/폼도 포함 안됨
`Lax`	대부분의 경우 차단되지만, GET 기반의 정적인 링크나 form 요청 등은 허용
`None`	모든 요청에 쿠키가 전송됨. 단, `Secure: true` 반드시 필요

요약

Strict → 가장 보안이 강함, 외부 요청 차단

Lax → 기본값. GET 요청만 허용

None → 크로스 도메인 요청 허용 (보안 취약 가능성 있음)

⚠️ SameSite=none은 위험할까?

단독으로 보면 그렇습니다.

쿠키를 통해 인증을 처리하면서 SameSite를 None으로 설정해두면, 타 도메인에서 악의적인 요청에도 인증 쿠키가 함께 전송될 수 있습니다.

하지만 요즘은 대부분 Authorization 헤더 기반의 JWT 인증 방식을 사용합니다:


Authorization: Bearer <token>

이 방식을 쓰면 CSRF에 강합니다. 왜냐하면 브라우저는 스스로 Authorization 헤더를 생성하지 못하기 때문입니다. 사용자가 직접 스크립트를 실행하거나 fetch 요청을 명시적으로 만들어야만 서버에서 인증을 통과할 수 있습니다.

결국 요즘의 인증 흐름은 이렇게 정리됩니다:

쿠키는 로그인 세션 유지 등 SSR 목적으로만 사용

실제 인증은 Authorization 헤더 기반으로 수행

SameSite=None을 쓰더라도, 서버는 Authorization으로 인증을 확인

이렇게 구성하면 보안성과 유연성을 모두 확보할 수 있습니다.

✍️ 정리하며

SameSite와 쿠키는 단순한 설정값처럼 보이지만, 보안과 밀접하게 연결되어 있습니다.

✅ 쿠키 기반 인증만을 사용하는 경우엔 SameSite=Strict 또는 Lax를 권장

✅ JWT 기반 인증을 도입했다면, SameSite=None + Secure + httpOnly 조합으로도 안전하게 운영 가능

✅ Server Side Rendering (SSR) 에서 로그인 상태 유지를 위해 쿠키를 사용할 수 있으나, 중요한 인증은 항상 Authorization 헤더를 기준으로 판단

쿠키는 여전히 유용한 도구입니다. 다만, 그 사용처와 동작 범위를 정확히 이해하고 있어야 진짜 안전한 인증 시스템을 만들 수 있습니다.

🧑‍💻 SSR에서 로그인 상태 유지 – 쿠키의 역할

많은 사람들이 JWT와 같은 토큰 기반 인증을 CSR(Client Side Rendering) 환경에서만 고려하지만, 실제로 SSR(Server Side Rendering) 환경에서도 유저의 로그인 상태를 유지하는 방식은 여전히 중요합니다.

특히 Next.js에서 페이지를 서버에서 렌더링할 경우, 클라이언트의 인증 정보를 서버에서 읽어야 현재 유저의 상태를 반영할 수 있습니다.

📦 쿠키를 활용한 SSR 인증 흐름

사용자가 로그인하면 서버는 Set-Cookie 헤더를 통해 accessToken 저장

이후 사용자가 브라우저를 통해 페이지에 접근할 때마다

브라우저는 자동으로 쿠키를 함께 전송

SSR 단계에서 서버는 이 쿠키를 읽고 인증 상태 확인 가능

🔧 예제: `Next.js` App Router에서 SSR 인증 처리


// app/layout.tsx or app/page.tsx
import { cookies } from 'next/headers'
import { decodeJwt } from '@/libs/utils/jwt'

export default async function Layout({ children }: { children: React.ReactNode }) {
  const cookieStore = cookies()
  const accessToken = cookieStore.get('access_token')?.value

  let user = null

  if (accessToken) {
    try {
      user = decodeJwt(accessToken)
    } catch (e) {
      console.warn('Invalid token')
    }
  }

  return (
    <html>
      <body>
        {user ? <Header user={user} /> : <Header />}
        {children}
      </body>
    </html>
  )
}

cookies()는 Next.js App Router의 서버 컴포넌트에서 사용 가능한 API입니다. 이 방식으로 SSR 단계에서도 로그인 정보를 확인할 수 있습니다.

🔐 인증 미들웨어로 보호할 수도 있음


// middleware.ts
import { NextRequest, NextResponse } from 'next/server'

export function middleware(req: NextRequest) {
  const token = req.cookies.get('access_token')?.value

  if (!token) {
    return NextResponse.redirect(new URL('/login', req.url))
  }

  return NextResponse.next()
}

export const config = {
  matcher: ['/dashboard/:path*', '/admin/:path*'], // 보호할 경로 지정
}

☝️ 쿠키 + SSR: 주의할 점

항목	설명
`SameSite`	크로스도메인 인증 요구 시 `None` + `Secure` 필요
`httpOnly`	클라이언트 JS에서 쿠키를 읽을 수 없도록 설정
`decodeJwt`	SSR에서는 외부 API 호출보다 JWT 디코딩이 빠르고 효율적
쿠키 만료	SSR 환경에서도 쿠키가 만료되면 SSR 시점에서 유저 정보 없음으로 처리됨

✅ 결론

CSR은 Authorization 헤더 기반

SSR은 쿠키 기반 인증 유지가 현재 가장 많이 쓰이는 패턴입니다.

Next.js와 같은 하이브리드 프레임워크에서는 이 두 전략을 병행하며, 보안성과 사용자 경험을 모두 지킬 수 있습니다.

사용자의 로그인 상태를 정확히 파악하고 싶다면, SSR에서는 쿠키를 활용한 JWT 파싱을 고려해보세요.

🔐 그렇다면 실제 로그인/로그아웃은 어떻게 구현할까?

앞서 설명한 것처럼, SSR 환경에서는 쿠키를 통해 로그인 상태를 유지할 수 있습니다. 그렇다면 로그인/로그아웃 처리와, 만약 쿠키가 위조되거나 만료된 경우 어떻게 대응할 수 있을지까지도 살펴보겠습니다.

1️⃣ 로그인 시 accessToken을 쿠키로 저장

사용자가 로그인에 성공하면 서버에서 accessToken을 Set-Cookie 헤더를 통해 브라우저에 전달합니다. 이 쿠키는 httpOnly, Secure, SameSite=None 등 보안 옵션과 함께 설정해야 합니다.


// app/api/auth/signin/route.ts
import { cookies } from 'next/headers'
import { serialize } from 'cookie'

export async function POST(req: NextRequest) {
  const { email, password } = await req.json()
  const { authToken } = await apiClient.auth.signIn({
    email,
    password,
    provider: 'email',
    platform: 'web',
  })

  const cookie = serialize('access_token', authToken.accessToken, {
    httpOnly: true,
    secure: true,
    sameSite: 'none',
    path: '/',
    maxAge: 60 * 60 * 24 * 7,
    domain: process.env.NODE_ENV === 'development' ? undefined : '.yourdomain.com',
  })

  return new Response(null, {
    status: 200,
    headers: {
      'Set-Cookie': cookie,
    },
  })
}

2️⃣ 로그아웃 시 쿠키 만료 처리

로그아웃을 처리할 때는 단순히 쿠키를 제거하면 됩니다. 이때 maxAge: 0 옵션을 주면 쿠키가 즉시 만료됩니다.


// app/api/auth/signout/route.ts
import { serialize } from 'cookie'

export async function POST() {
  const expiredCookie = serialize('access_token', '', {
    httpOnly: true,
    secure: true,
    sameSite: 'none',
    path: '/',
    maxAge: 0,
    domain: process.env.NODE_ENV === 'development' ? undefined : '.yourdomain.com',
  })

  return new Response(null, {
    status: 200,
    headers: {
      'Set-Cookie': expiredCookie,
    },
  })
}

3️⃣ 백엔드에서 401 반환 시 자동 로그아웃 처리

쿠키가 위조되었거나 만료된 경우, 서버 API는 401 Unauthorized를 반환하게 됩니다. 이때 클라이언트에서는 자동으로 signout API를 호출하고 로그인 페이지로 리디렉션할 수 있습니다.


// libs/fetchWithAuth.ts
export async function fetchWithAuth(input: RequestInfo, init: RequestInit = {}) {
  const res = await fetch(input, {
    ...init,
    credentials: 'include', // 쿠키 포함
  })

  if (res.status === 401) {
    await fetch('/api/auth/signout', { method: 'POST' })
    if (typeof window !== 'undefined') {
      window.location.href = '/login?expired=1'
    }
    return null
  }

  return res.json()
}

4️⃣ SSR 환경에서도 유저 정보 유지

서버에서 렌더링할 때는 브라우저가 보낸 쿠키를 읽어 유저 정보를 파악할 수 있습니다. 보통은 decodeJwt 등을 통해 accessToken에서 유저 정보를 디코딩하는 식으로 처리합니다.


// app/layout.tsx
import { cookies } from 'next/headers'
import { decodeJwt } from '@/libs/utils/jwt'

export default async function Layout({ children }: { children: React.ReactNode }) {
  const token = cookies().get('access_token')?.value
  let user = null

  if (token) {
    try {
      user = decodeJwt(token)
    } catch {
      // 쿠키가 위조되었거나 만료됨
    }
  }

  return (
    <html>
      <body>
        {user ? <Header user={user} /> : <Header />}
        {children}
      </body>
    </html>
  )
}

✅ 쿠키를 사용한 SSR + 로그인과 로그아웃 처리 정리

우리가 SSR 환경에서도 로그인 상태를 유지하고, 보안성을 해치지 않으려면 아래와 같은 전략이 필요합니다:

쿠키는 httpOnly, Secure, SameSite=None 등 보안 옵션과 함께 설정

CSR 환경에서는 Authorization 헤더로 인증, SSR에서는 쿠키를 파싱하여 유저 상태 유지

백엔드에서 401 반환 시 클라이언트는 자동으로 로그아웃 처리

위조된 토큰이나 만료된 쿠키는 SSR 시에도 파싱 실패로 처리

이처럼 CSR과 SSR 환경 모두에서 일관성 있게 로그인 상태를 유지하면서, 보안성을 확보하는 방식이 요즘 인증 시스템의 핵심입니다.

그렇다면 Nextjs에서 middleware에서의 처리는 어떤지 알아보겠습니다.

🧱 Middleware로 보호되는 인증 라우트

지금까지 쿠키를 통해 SSR 환경에서도 로그인 상태를 유지하는 방법을 살펴봤다면, 이제는 로그인이 필요한 페이지를 사전에 차단하거나 리디렉션 시키는 방법도 알아야 합니다.

Next.js에서는 middleware.ts 파일을 통해 클라이언트가 요청을 서버로 보내기 전에 특정 조건을 검사하고 흐름을 제어할 수 있습니다.

👮 로그인 유무에 따라 페이지 접근 제한하기

아래는 사용자가 특정 보호 페이지(/dashboard나 /admin 등)에 접근할 때, 쿠키 기반으로 로그인 여부를 검사하고 로그인하지 않은 경우 로그인 페이지로 리디렉션하는 예시입니다:


// middleware.ts
import { NextRequest, NextResponse } from 'next/server'
import { jwtVerify } from 'jose'

const COOKIE_ACCESS_TOKEN_KEY = 'access_token'

export async function middleware(req: NextRequest) {
  const token = req.cookies.get(COOKIE_ACCESS_TOKEN_KEY)?.value

  if (!token) {
    // 로그인하지 않은 사용자 → 로그인 페이지로
    return NextResponse.redirect(new URL('/login', req.url))
  }

  try {
    // 토큰 유효성 검사
    await jwtVerify(token, new TextEncoder().encode(process.env.JWT_SECRET))
    return NextResponse.next()
  } catch {
    // 토큰 위조 혹은 만료 → 쿠키 삭제 + 로그인 페이지로
    const response = NextResponse.redirect(new URL('/login', req.url))
    response.cookies.set(COOKIE_ACCESS_TOKEN_KEY, '', {
      httpOnly: true,
      secure: true,
      sameSite: 'none',
      maxAge: 0,
      path: '/',
      domain: process.env.NODE_ENV === 'development' ? undefined : '.yourdomain.com',
    })
    return response
  }
}

🔍 어떤 경로에만 middleware를 적용할까?

아래처럼 config에서 middleware를 실행할 경로를 지정할 수 있습니다. 로그인하지 않은 사용자가 직접 접속해서는 안 되는 페이지에만 제한을 걸어두면 됩니다.


export const config = {
  matcher: ['/dashboard/:path*', '/admin/:path*', '/mypage/:path*'],
}

💡 middleware를 쓸 때 주의할 점

주의사항	설명
응답 속도	middleware는 모든 요청 전 처리되므로 최소한의 로직만 포함할 것
JWT Secret	서버에선 `.env`를 통해 토큰 검증 시 필요한 secret을 반드시 제공
쿠키 옵션	쿠키가 `httpOnly`, `Secure`, `SameSite` 설정이 되어 있어야 안전하게 동작함
redirect loop	로그인 페이지 접근도 middleware에 걸리지 않도록 matcher 경로 주의

✅ 정리하면

SSR에서는 쿠키를 파싱해서 사용자 인증 정보를 확인할 수 있고

CSR에서는 fetch로 인증 상태를 처리하며

middleware를 활용하면 인증이 필요한 페이지 접근을 사전 차단할 수 있습니다.

이러한 전략을 조합하면, 서버/클라이언트/라우팅 모든 측면에서 안전하고 일관된 인증 흐름을 구현할 수 있습니다.

🔁 Refresh Token 기반 재발급과 RBAC까지

실제 운영 환경에서는 accessToken이 짧게 만료되는 구조를 채택하는 경우가 많습니다. 이때는 middleware에서 accessToken이 만료되었더라도, refreshToken이 유효하다면 새로운 accessToken을 발급받아 다시 정상 요청을 처리할 수 있게 만들어야 합니다.

또한 관리자가 접근할 수 있는 /admin, 유저만 접근 가능한 /mypage 같은 페이지를 분기하려면 Role 기반 인증(RBAC) 도 함께 고려해야 합니다.

🪙 Refresh Token 기반 재발급 구조


// middleware.ts
import { NextRequest, NextResponse } from 'next/server'
import { jwtVerify, decodeJwt } from 'jose'

const ACCESS_COOKIE = 'access_token'
const REFRESH_COOKIE = 'refresh_token'

async function verify(token: string) {
  return await jwtVerify(token, new TextEncoder().encode(process.env.JWT_SECRET))
}

export async function middleware(req: NextRequest) {
  const accessToken = req.cookies.get(ACCESS_COOKIE)?.value
  const refreshToken = req.cookies.get(REFRESH_COOKIE)?.value

  // 1. accessToken이 있고 유효하면 그대로 통과
  if (accessToken) {
    try {
      await verify(accessToken)
      return NextResponse.next()
    } catch {
      // 계속 진행 (2번으로 넘어감)
    }
  }

  // 2. accessToken이 만료되었고, refreshToken으로 재발급 시도
  if (refreshToken) {
    try {
      const { payload } = await verify(refreshToken)

      // refreshToken 유효 → 새로운 accessToken 생성
      const newAccessToken = generateNewAccessToken(payload) // JWT 재발급 함수

      const response = NextResponse.next()
      response.cookies.set(ACCESS_COOKIE, newAccessToken, {
        httpOnly: true,
        secure: true,
        sameSite: 'none',
        path: '/',
        maxAge: 60 * 15, // 15분
        domain: process.env.NODE_ENV === 'development' ? undefined : '.yourdomain.com',
      })
      return response
    } catch {
      // refreshToken도 유효하지 않음 → 로그인 페이지로
    }
  }

  // 3. 로그인 필요
  return NextResponse.redirect(new URL('/login', req.url))
}

🔧 여기서 generateNewAccessToken() 함수는 서버 내부에 JWT 재발급 로직으로 따로 정의되어야 하며, 보통은 사용자 ID와 Role을 payload로 포함시킵니다.

🧑‍💼 RBAC (Role-Based Access Control)

middleware에서 유저의 role까지 검사해서 라우팅 제한을 걸 수도 있습니다.


const ADMIN_PATHS = ['/admin', '/admin/settings']

export async function middleware(req: NextRequest) {
  const token = req.cookies.get(ACCESS_COOKIE)?.value

  if (!token) {
    return NextResponse.redirect(new URL('/login', req.url))
  }

  try {
    const { payload } = await verify(token)

    const userRole = payload.role as string
    const pathname = req.nextUrl.pathname

    if (ADMIN_PATHS.some(path => pathname.startsWith(path)) && userRole !== 'admin') {
      return NextResponse.redirect(new URL('/unauthorized', req.url))
    }

    return NextResponse.next()
  } catch {
    return NextResponse.redirect(new URL('/login', req.url))
  }
}

✅ 최종 요약

기능	처리 방식
로그인 시	accessToken + refreshToken 쿠키 저장
accessToken 만료 시	middleware에서 refreshToken 검증 후 재발급
refreshToken도 만료 시	로그인 페이지로 리디렉션
SSR 렌더링 시 인증 상태 유지	쿠키 파싱 후 토큰 디코딩
관리자 전용 페이지 보호	role 검사 후 접근 제한 (RBAC)

이처럼 Next.js의 middleware, JWT, cookie, role 기반 제어, 토큰 재발급을 조합하면 실제 서비스에서 필요한 인증 로직을 완전하게 구현할 수 있습니다.