ファイル構造:

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>
);
}

説明:

• ルート定義: app ディレクトリの直下にある page.tsx ファイルは / ルートに対応しています。
• レンダリング: このコンポーネントはホームページのコンテンツをレンダリングします。
• レイアウト統合: 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>
)
}

説明:

• ルート定義: about フォルダー内の page.tsx ファイルは /about ルートに対応しています。
• レンダリング: このコンポーネントは、about ページのコンテンツをレンダリングします。

動的ルートは、変数セグメントを持つパスを処理できるようにし、アプリケーションが ID やスラグなどのパラメータに基づいてコンテンツを表示できるようにします。

例: /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>
);
}

説明:

• 動的セグメント: [id] はルート内の動的セグメントを示し、URLから id パラメータをキャプチャします。
• パラメータへのアクセス: params オブジェクトには動的パラメータが含まれ、コンポーネント内でアクセス可能です。
• ルートマッチング: /posts/* に一致する任意のパス、例えば /posts/1、/posts/abc などは、このコンポーネントによって処理されます。

Next.js はネストされたルーティングをサポートしており、ディレクトリ構造を反映した階層的なルート構造を可能にします。

例: /dashboard/settings/profile ルート

ファイル構造:

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>
);
}

説明:

• 深いネスト: dashboard/settings/profile/ 内の page.tsx ファイルは /dashboard/settings/profile ルートに対応しています。
• 階層の反映: ディレクトリ構造は URL パスを反映し、保守性と明確性を高めます。

キャッチオールルートは、複数のネストされたセグメントや不明なパスを処理し、ルート処理の柔軟性を提供します。

例: /* ルート

ファイル構造:

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>
)
}

説明:

• キャッチオールセグメント: [...slug] は残りのパスセグメントを配列としてキャプチャします。
• 使用法: ユーザー生成のパスやネストされたカテゴリなどの動的ルーティングシナリオを処理するのに便利です。
• ルートマッチング: /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 に悪意のあるコンテンツが含まれていると、意図しないコードの実行につながる可能性があります。

これは、攻撃者がクライアント側のパスを操作して、クロスサイトリクエストフォージェリ（CSRF）などの意図しないアクションを実行できる脆弱性です。サーバー側のパストラバーサルがサーバーのファイルシステムをターゲットにするのに対し、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の悪用:

• 悪意のある入力: 攻撃者は、filePathを操作したURL（例: ../deleteFile/config.json）を作成する。
• 結果としてのAPI呼び出し: クライアント側のコードが/api/files/../deleteFile/config.jsonにリクエストを送信する。
• サーバーの処理: サーバーがfilePathを検証しない場合、リクエストを処理し、機密ファイルを削除または露出させる可能性がある。

3. CSRFの実行:

• 作成されたリンク: 攻撃者は被害者にリンクを送信するか、操作されたfilePathでダウンロードリクエストをトリガーする悪意のあるスクリプトを埋め込む。
• 結果: 被害者は知らずにアクションを実行し、無許可のファイルアクセスまたは削除につながる。

なぜ脆弱なのか

• 入力検証の欠如: クライアント側が任意のfilePath入力を許可し、パストラバーサルを可能にしている。
• クライアント入力の信頼: サーバー側のAPIがfilePathをサニタイズせずに信頼して処理している。
• 潜在的なAPIアクション: APIエンドポイントが状態を変更するアクション（例: 削除、ファイルの変更）を実行する場合、CSPTを介して悪用される可能性がある。

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" },
})
}

説明:

• 複数のエクスポート: 各HTTPメソッド（GET、PUT、DELETE）には独自のエクスポートされた関数があります。
• パラメータ: 2番目の引数はparamsを介してルートパラメータへのアクセスを提供します。
• 強化されたレスポンス: レスポンスオブジェクトに対するより大きな制御が可能で、正確なヘッダーとステータスコードの管理ができます。

Next.js 13+は、キャッチオールルートやネストされたAPIルートなどの高度なルーティング機能をサポートしており、より動的でスケーラブルなAPI構造を可能にします。

キャッチオールルートの例:

// 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オブジェクトを介して複数のルートパラメータに簡単にアクセスできます。

pagesディレクトリ内のAPIルート (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 default を使用します。
• 関数シグネチャ: ハンドラは req (HTTP リクエスト) と res (HTTP レスポンス) オブジェクトを受け取ります。
• ルーティング: ファイル名 (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メソッドのロジックを明確に分離する。
• レスポンスの一貫性: クライアント側の処理を容易にするために、一貫したレスポンス構造を確保する。
• エラーハンドリング: サポートされていないメソッドや予期しないエラーを優雅に処理する。

セキュリティヘッダーは、ブラウザにコンテンツの取り扱い方法を指示することで、アプリケーションのセキュリティを強化します。これにより、クロスサイトスクリプティング（XSS）、クリックジャッキング、MIMEタイプスニッフィングなどのさまざまな攻撃を軽減します：

• コンテンツセキュリティポリシー (CSP)
• X-Frame-Options
• X-Content-Type-Options
• Strict-Transport-Security (HSTS)
• リファラーポリシー

例:

// 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キーやデータベースの認証情報などの機密情報を安全に管理し、クライアントに露出しないようにします。

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）、クライアント側でアクセス可能になります。

攻撃者がそれを悪用する方法:

機密変数がクライアントに公開されると、攻撃者はクライアント側のコードやネットワークリクエストを調査することでそれらを取得し、API、データベース、または他のサービスへの不正アクセスを得ることができます。

アプリケーション内でURLのリダイレクションとリライトを管理し、ユーザーが適切に誘導されるようにし、オープンリダイレクトの脆弱性を導入しないようにします。

a. オープンリダイレクト脆弱性

悪い構成の例:

// next.config.js

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

問題:

• 動的な宛先: ユーザーが任意のURLを指定できるため、オープンリダイレクト攻撃を可能にします。
• ユーザー入力の信頼: ユーザーが提供したURLに対して検証なしにリダイレクトすることは、フィッシング、マルウェアの配布、または認証情報の盗難につながる可能性があります。

攻撃者がどのように悪用するか:

攻撃者は、あなたのドメインから発信されているように見える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
},
}

問題:

• 機密パスの露出: 機密ディレクトリをエイリアス化し、クライアント側アクセスを許可すると、機密情報が漏洩する可能性があります。
• 秘密のバンドル: 機密ファイルがクライアント用にバンドルされると、その内容はソースマップやクライアント側コードの検査を通じてアクセス可能になります。

攻撃者がどのように悪用するか:

攻撃者はアプリケーションのディレクトリ構造にアクセスしたり再構築したりでき、機密ファイルやデータを見つけて悪用する可能性があります。