파일 구조:

my-nextjs-app/
├── app/
│   ├── layout.tsx
│   └── page.tsx
├── public/
├── next.config.js
└── ...

주요 파일:

• app/page.tsx: 루트 경로 /에 대한 요청을 처리합니다.
• app/layout.tsx: 애플리케이션의 레이아웃을 정의하고 모든 페이지를 감쌉니다.

구현:

tsxCopy code// app/page.tsx

export default function HomePage() {
return (
<div>
<h1>Welcome to the Home Page!</h1>
<p>This is the root route.</p>
</div>
);
}

설명:

• 라우트 정의: page.tsx 파일은 app 디렉터리 바로 아래에 위치하며 / 라우트에 해당합니다.
• 렌더링: 이 컴포넌트는 홈 페이지의 콘텐츠를 렌더링합니다.
• 레이아웃 통합: HomePage 컴포넌트는 layout.tsx에 의해 래핑되어 있으며, 여기에는 헤더, 푸터 및 기타 공통 요소를 포함할 수 있습니다.

예시: /about 라우트

파일 구조:

arduinoCopy codemy-nextjs-app/
├── app/
│   ├── about/
│   │   └── page.tsx
│   ├── layout.tsx
│   └── page.tsx
├── public/
├── next.config.js
└── ...

구현:

// app/about/page.tsx

export default function AboutPage() {
return (
<div>
<h1>About Us</h1>
<p>Learn more about our mission and values.</p>
</div>
)
}

설명:

• 라우트 정의: page.tsx 파일은 about 폴더 안에 위치하며 /about 경로에 대응합니다.
• 렌더링: 이 컴포넌트는 about 페이지의 내용을 렌더링합니다.

동적 라우트를 사용하면 가변 세그먼트를 가진 경로를 처리할 수 있어, ID나 slug 같은 파라미터에 따라 애플리케이션이 콘텐츠를 표시할 수 있습니다.

예시: /posts/[id] 라우트

파일 구조:

arduinoCopy codemy-nextjs-app/
├── app/
│   ├── posts/
│   │   └── [id]/
│   │       └── page.tsx
│   ├── layout.tsx
│   └── page.tsx
├── public/
├── next.config.js
└── ...

구현:

tsxCopy code// app/posts/[id]/page.tsx

import { useRouter } from 'next/navigation';

interface PostProps {
params: { id: string };
}

export default function PostPage({ params }: PostProps) {
const { id } = params;
// Fetch post data based on 'id'

return (
<div>
<h1>Post #{id}</h1>
<p>This is the content of post {id}.</p>
</div>
);
}

설명:

• Dynamic Segment: [id]는 라우트에서 동적 세그먼트를 나타내며, URL에서 id 파라미터를 캡처합니다.
• Accessing Parameters: params 객체는 동적 파라미터를 포함하며 컴포넌트 내에서 접근할 수 있습니다.
• Route Matching: /posts/*와 매칭되는 모든 경로(예: /posts/1, /posts/abc 등)는 이 컴포넌트에 의해 처리됩니다.

Next.js는 디렉토리 레이아웃을 반영하는 계층적 라우트 구조를 허용하는 중첩 라우팅을 지원합니다.

Example: /dashboard/settings/profile Route

File Structure:

arduinoCopy codemy-nextjs-app/
├── app/
│   ├── dashboard/
│   │   ├── settings/
│   │   │   └── profile/
│   │   │       └── page.tsx
│   │   └── page.tsx
│   ├── layout.tsx
│   └── page.tsx
├── public/
├── next.config.js
└── ...

구현:

tsxCopy code// app/dashboard/settings/profile/page.tsx

export default function ProfileSettingsPage() {
return (
<div>
<h1>Profile Settings</h1>
<p>Manage your profile information here.</p>
</div>
);
}

설명:

• 깊은 중첩: page.tsx 파일은 dashboard/settings/profile/ 내부에 있으며 /dashboard/settings/profile 라우트에 해당합니다.
• 계층 반영: 디렉터리 구조는 URL 경로를 반영하여 유지보수성과 명확성을 향상시킵니다.

Catch-All 라우트는 여러 중첩 세그먼트나 알 수 없는 경로를 처리하여 라우트 처리에 유연성을 제공합니다.

예시: /* 라우트

파일 구조:

my-nextjs-app/
├── app/
│   ├── [..slug]/
│   │   └── page.tsx
│   ├── layout.tsx
│   └── page.tsx
├── public/
├── next.config.js
└── ...

구현:

// app/[...slug]/page.tsx

interface CatchAllProps {
params: { slug: string[] }
}

export default function CatchAllPage({ params }: CatchAllProps) {
const { slug } = params
const fullPath = `/${slug.join("/")}`

return (
<div>
<h1>Catch-All Route</h1>
<p>You have navigated to: {fullPath}</p>
</div>
)
}

설명:

• Catch-All Segment: [...slug]는 나머지 경로 세그먼트를 배열로 캡처합니다.
• Usage: 동적 라우팅 시나리오(예: 사용자 생성 경로, 중첩 카테고리 등)를 처리하는 데 유용합니다.
• Route Matching: 경로(예: /anything/here, /foo/bar/baz 등)는 이 컴포넌트에 의해 처리됩니다.

XSS 공격은 악성 스크립트가 신뢰된 웹사이트에 주입될 때 발생합니다. 공격자는 사용자의 브라우저에서 스크립트를 실행해 데이터를 훔치거나 사용자를 대신해 조작을 수행할 수 있습니다.

취약한 코드 예시:

// Dangerous: Injecting user input directly into HTML
function Comment({ userInput }) {
return <div dangerouslySetInnerHTML={{ __html: userInput }} />
}

취약한 이유: dangerouslySetInnerHTML을 신뢰할 수 없는 입력과 함께 사용하면 공격자가 악성 스크립트를 주입할 수 있습니다.

사용자 입력이 템플릿에서 부적절하게 처리될 때 발생하며, 공격자가 템플릿이나 표현식을 주입하고 실행할 수 있게 합니다.

취약한 코드 예시:

import React from "react"
import ejs from "ejs"

function RenderTemplate({ template, data }) {
const html = ejs.render(template, data)
return <div dangerouslySetInnerHTML={{ __html: html }} />
}

왜 취약한가: 만약 template 또는 data에 악의적인 내용이 포함되면, 의도하지 않은 코드가 실행될 수 있습니다.

이 취약점은 공격자가 클라이언트 측 경로를 조작하여 Cross-Site Request Forgery (CSRF)와 같은 의도하지 않은 동작을 수행하게 할 수 있습니다. 서버의 파일시스템을 대상으로 하는 server-side path traversal과 달리, CSPT는 정당한 API 요청을 악의적인 엔드포인트로 우회시키기 위해 클라이언트 측 메커니즘을 악용하는 데 중점을 둡니다.

취약한 코드 예:

Next.js 애플리케이션이 사용자가 파일을 업로드하고 다운로드하도록 허용합니다. 다운로드 기능은 클라이언트 측에 구현되어 있으며, 사용자가 다운로드할 파일 경로를 지정할 수 있습니다.

// pages/download.js
import { useState } from "react"

export default function DownloadPage() {
const [filePath, setFilePath] = useState("")

const handleDownload = () => {
fetch(`/api/files/${filePath}`)
.then((response) => response.blob())
.then((blob) => {
const url = window.URL.createObjectURL(blob)
const a = document.createElement("a")
a.href = url
a.download = filePath
a.click()
})
}

return (
<div>
<h1>Download File</h1>
<input
type="text"
value={filePath}
onChange={(e) => setFilePath(e.target.value)}
placeholder="Enter file path"
/>
<button onClick={handleDownload}>Download</button>
</div>
)
}

공격 시나리오

1. 공격자의 목표: filePath를 조작해 중요한 파일(예: admin/config.json)을 삭제하는 CSRF 공격을 수행.
2. CSPT 악용:

• Malicious Input: 공격자는 ../deleteFile/config.json와 같은 조작된 filePath를 포함한 URL을 제작.
• Resulting API Call: 클라이언트 측 코드가 /api/files/../deleteFile/config.json로 요청을 보냄.
• 서버 처리: 서버가 filePath를 검증하지 않으면 요청을 처리하여 민감한 파일을 삭제하거나 노출할 수 있음.

3. CSRF 실행:

• Crafted Link: 공격자가 피해자에게 링크를 보내거나 조작된 스크립트를 삽입하여 조작된 filePath로 다운로드 요청을 발생시킴.
• Outcome: 피해자가 의도치 않게 해당 동작을 실행하여 권한 없는 파일 접근 또는 삭제가 발생.

Next.js 13+에서는 같은 route.js 또는 route.ts 파일 내에서 특정 HTTP 메서드에 대한 핸들러를 정의할 수 있어 코드가 더 명확하고 체계적으로 구성됩니다.

예시:

// app/api/users/[id]/route.js

export async function GET(request, { params }) {
const { id } = params
// Fetch user data based on 'id'
return new Response(JSON.stringify({ userId: id, name: "Jane Doe" }), {
status: 200,
headers: { "Content-Type": "application/json" },
})
}

export async function PUT(request, { params }) {
const { id } = params
// Update user data based on 'id'
return new Response(JSON.stringify({ message: `User ${id} updated.` }), {
status: 200,
headers: { "Content-Type": "application/json" },
})
}

export async function DELETE(request, { params }) {
const { id } = params
// Delete user based on 'id'
return new Response(JSON.stringify({ message: `User ${id} deleted.` }), {
status: 200,
headers: { "Content-Type": "application/json" },
})
}

설명:

• Multiple Exports: 각 HTTP 메서드(GET, PUT, DELETE)는 각각 고유한 export된 함수를 가집니다.
• Parameters: 두 번째 인수는 params를 통해 라우트 매개변수에 접근할 수 있게 합니다.
• Enhanced Responses: 응답 객체에 대한 더 세밀한 제어를 제공하여 헤더와 상태 코드를 정확히 관리할 수 있습니다.

Next.js 13+는 catch-all routes 및 중첩 API 라우트와 같은 고급 라우팅 기능을 지원하여 더 동적이고 확장 가능한 API 구조를 만들 수 있게 합니다.

Catch-All Route 예시:

// app/api/[...slug]/route.js

export async function GET(request, { params }) {
const { slug } = params
// Handle dynamic nested routes
return new Response(JSON.stringify({ slug }), {
status: 200,
headers: { "Content-Type": "application/json" },
})
}

설명:

• 문법: [...]는 모든 경로를 포괄하는 세그먼트를 나타내며, 모든 중첩된 경로를 캡처합니다.
• 용도: 다양한 경로 깊이 또는 동적 세그먼트를 처리해야 하는 API에 유용합니다.

중첩 라우트 예시:

// app/api/posts/[postId]/comments/[commentId]/route.js

export async function GET(request, { params }) {
const { postId, commentId } = params
// Fetch specific comment for a post
return new Response(
JSON.stringify({ postId, commentId, comment: "Great post!" }),
{
status: 200,
headers: { "Content-Type": "application/json" },
}
)
}

설명:

• 깊은 중첩: 리소스 관계를 반영하는 계층형 API 구조를 허용합니다.
• 매개변수 접근: params 객체를 통해 여러 라우트 매개변수에 쉽게 접근할 수 있습니다.

API Routes in the pages Directory (Next.js 12 및 이전)

Next.js 13이 app 디렉토리와 향상된 라우팅 기능을 도입하기 전에는, API 라우트가 주로 pages 디렉토리 내에서 정의되었습니다. 이 방식은 Next.js 12 및 이전 버전에서 여전히 널리 사용되고 지원됩니다.

기본 API 라우트

파일 구조:

goCopy codemy-nextjs-app/
├── pages/
│   └── api/
│       └── hello.js
├── package.json
└── ...

구현:

javascriptCopy code// pages/api/hello.js

export default function handler(req, res) {
res.status(200).json({ message: 'Hello, World!' });
}

설명:

• 위치: API 라우트는 pages/api/ 디렉터리 아래에 위치합니다.
• Export: 핸들러 함수를 정의할 때 export default를 사용합니다.
• 함수 시그니처: 핸들러는 req (HTTP request) 및 res (HTTP response) 객체를 받습니다.
• 라우팅: 파일 이름 (hello.js)은 엔드포인트 /api/hello에 매핑됩니다.

동적 API 라우트

파일 구조:

bashCopy codemy-nextjs-app/
├── pages/
│   └── api/
│       └── users/
│           └── [id].js
├── package.json
└── ...

구현:

javascriptCopy code// pages/api/users/[id].js

export default function handler(req, res) {
const {
query: { id },
method,
} = req;

switch (method) {
case 'GET':
// Fetch user data based on 'id'
res.status(200).json({ userId: id, name: 'John Doe' });
break;
case 'PUT':
// Update user data based on 'id'
res.status(200).json({ message: `User ${id} updated.` });
break;
case 'DELETE':
// Delete user based on 'id'
res.status(200).json({ message: `User ${id} deleted.` });
break;
default:
res.setHeader('Allow', ['GET', 'PUT', 'DELETE']);
res.status(405).end(`Method ${method} Not Allowed`);
}
}

설명:

• 동적 세그먼트: 대괄호([id].js)는 동적 라우트 세그먼트를 나타냅니다.
• 파라미터 접근: req.query.id를 사용하여 동적 매개변수에 접근하세요.
• 메서드 처리: 조건문을 사용해 서로 다른 HTTP 메서드(GET, PUT, DELETE 등)를 처리하세요.

서로 다른 HTTP 메서드 처리

기본 API 라우트 예제는 단일 함수 내에서 모든 HTTP 메서드를 처리하지만, 가독성과 유지보수성을 위해 각 메서드를 명시적으로 처리하도록 코드를 구조화할 수 있습니다.

예제:

javascriptCopy code// pages/api/posts.js

export default async function handler(req, res) {
const { method } = req;

switch (method) {
case 'GET':
// Handle GET request
res.status(200).json({ message: 'Fetching posts.' });
break;
case 'POST':
// Handle POST request
res.status(201).json({ message: 'Post created.' });
break;
default:
res.setHeader('Allow', ['GET', 'POST']);
res.status(405).end(`Method ${method} Not Allowed`);
}
}

모범 사례:

• 관심사의 분리: 서로 다른 HTTP 메서드에 대한 로직을 명확히 분리하세요.
• 응답 일관성: 클라이언트 측 처리를 용이하게 하기 위해 응답 구조를 일관되게 유지하세요.
• 오류 처리: 지원되지 않는 메서드와 예기치 않은 오류를 우아하게 처리하세요.

보안 헤더는 브라우저에게 콘텐츠 처리 방법을 지시하여 애플리케이션의 보안을 강화합니다. 이는 Cross-Site Scripting (XSS), Clickjacking, MIME type sniffing 같은 다양한 공격을 완화하는 데 도움을 줍니다:

• Content Security Policy (CSP)
• X-Frame-Options
• X-Content-Type-Options
• Strict-Transport-Security (HSTS)
• Referrer Policy

예시:

// next.config.js

module.exports = {
async headers() {
return [
{
source: "/(.*)", // Apply to all routes
headers: [
{
key: "X-Frame-Options",
value: "DENY",
},
{
key: "Content-Security-Policy",
value:
"default-src *; script-src 'self' 'unsafe-inline' 'unsafe-eval';",
},
{
key: "X-Content-Type-Options",
value: "nosniff",
},
{
key: "Strict-Transport-Security",
value: "max-age=63072000; includeSubDomains; preload", // Enforces HTTPS
},
{
key: "Referrer-Policy",
value: "no-referrer", // Completely hides referrer
},
// Additional headers...
],
},
]
},
}

Next.js는 성능을 위해 이미지를 최적화하지만, 잘못된 구성은 신뢰할 수 없는 소스가 악의적인 콘텐츠를 주입하도록 허용하는 등 보안 취약점으로 이어질 수 있습니다.

잘못된 구성 예시:

// next.config.js

module.exports = {
images: {
domains: ["*"], // Allows images from any domain
},
}

문제:

• '*': 신뢰할 수 없거나 악의적인 도메인을 포함해 모든 외부 소스에서 이미지를 로드하도록 허용합니다. 공격자는 악성 페이로드를 포함한 이미지나 사용자를 오도하는 콘텐츠를 호스팅할 수 있습니다.
• 또 다른 문제는 누구나 이미지를 업로드할 수 있는 도메인(예: raw.githubusercontent.com)을 허용하는 것입니다.

공격자가 이를 악용하는 방법:

악성 소스에서 이미지를 주입함으로써, 공격자는 피싱 공격을 수행하거나 오해를 불러일으키는 정보를 표시하거나 이미지 렌더링 라이브러리의 취약점을 악용할 수 있습니다.

API keys 및 database credentials 같은 민감한 정보를 클라이언트에 노출하지 않도록 안전하게 관리하세요.

a. 민감한 변수 노출

잘못된 구성 예시:

// next.config.js

module.exports = {
env: {
SECRET_API_KEY: process.env.SECRET_API_KEY, // Exposed to the client
NEXT_PUBLIC_API_URL: process.env.NEXT_PUBLIC_API_URL, // Correctly prefixed for client
},
}

문제:

• SECRET_API_KEY: NEXT_PUBLIC_ 접두사가 없으면 Next.js는 변수를 클라이언트에 노출하지 않습니다. 하지만 실수로 접두사가 붙으면 (예: NEXT_PUBLIC_SECRET_API_KEY) 클라이언트 측에서 접근 가능해집니다.

공격자가 이를 악용하는 방법:

민감한 변수가 클라이언트에 노출되면, 공격자는 클라이언트 측 코드나 네트워크 요청을 검사하여 이를 획득하고, APIs, databases 또는 기타 서비스에 대한 무단 접근 권한을 얻을 수 있습니다.

애플리케이션 내에서 URL 리디렉션과 재작성(rewrites)을 관리하여 사용자가 적절히 이동되도록 하면서 open redirect vulnerabilities를 유발하지 않도록 하세요.

a. Open Redirect Vulnerability

잘못된 구성 예:

// next.config.js

module.exports = {
async redirects() {
return [
{
source: "/redirect",
destination: (req) => req.query.url, // Dynamically redirects based on query parameter
permanent: false,
},
]
},
}

문제:

• 동적 목적지 (Dynamic Destination): 사용자가 임의의 URL을 지정할 수 있게 하여 open redirect attacks를 가능하게 합니다.
• 사용자 입력 신뢰 (Trusting User Input): 사용자가 제공한 URL로 검증 없이 리디렉션하면 phishing, malware distribution 또는 credential theft로 이어질 수 있습니다.

공격자가 이를 악용하는 방법:

공격자는 귀사의 도메인에서 온 것처럼 보이지만 사용자를 악성 사이트로 리다이렉트하는 URL을 조작할 수 있습니다. 예를 들어:

https://yourdomain.com/redirect?url=https://malicious-site.com

원래 도메인을 신뢰하는 사용자는 자신도 모르게 악성 웹사이트로 이동할 수 있습니다.

Next.js 애플리케이션의 Webpack 구성을 사용자화하면 주의하지 않으면 의도치 않게 보안 취약점이 발생할 수 있습니다.

a. 민감한 모듈 노출

잘못된 구성 예시:

// next.config.js

module.exports = {
webpack: (config, { isServer }) => {
if (!isServer) {
config.resolve.alias["@sensitive"] = path.join(__dirname, "secret-folder")
}
return config
},
}

Problem:

• Exposing Sensitive Paths: 민감한 디렉터리를 alias 처리하고 클라이언트 측 접근을 허용하면 기밀 정보가 leak될 수 있습니다.
• Bundling Secrets: 민감한 파일이 클라이언트용으로 번들되면, 그 내용은 source maps를 통해 또는 클라이언트 측 코드를 검사하여 접근 가능해집니다.

How attackers abuse it:

공격자는 애플리케이션의 디렉터리 구조에 접근하거나 이를 재구성하여 민감한 파일이나 데이터를 찾아 악용할 수 있습니다.