Reactのセキュリティと安定性（XSS・CSRF対策からOAuth、サードパーティ管理まで）- Reactを理解して使う12日目
📅
dangerouslySetInnerHTML を不用意に使った例です。import React from "react";
function UserProfile({ bio }: { bio: string }) {
// 사용자가 입력한 bio 내용을 HTML로 해석하여 그대로 삽입
// 절대 이렇게 사용하면 안 됩니다!
return (
<div>
<h3>소개</h3>
<div dangerouslySetInnerHTML={{ __html: bio }} />
</div>
);
}
const UserProfilePage = () => {
// 만약 공격자가 bio에 다음과 같은 악성 스크립트를 입력했다면?
const bio =
'안녕하세요! 저는 웹 개발자입니다. <script>alert("XSS 공격 성공! 쿠키: " + document.cookie);</script>';
return (
<div>
<h1>사용자 프로필</h1>
<UserProfile bio={bio} />
{/* 이 컴포넌트가 렌더링되면, 다른 사용자의 브라우저에서 스크립트가 실행되어 경고창이 뜨고 쿠키 정보가 노출될 수 있습니다. */}
</div>
);
};
export default UserProfilePage;
dangerouslySetInnerHTML で描画すると、閲覧者のブラウザでスクリプトが実行され、Cookie情報の窃取など深刻な問題につながる可能性があります。{} の内容を基本的に文字列として扱い、HTMLやスクリプトと解釈される可能性のある特殊文字、例えば <、>、& を自動で<script> タグを渡しても、ブラウザは通常のテキストとして認識し、実行しません。import React from "react";
function UserProfile({ bio }: { bio: string }) {
// 사용자가 입력한 bio 내용을 HTML로 해석하여 그대로 삽입
// 절대 이렇게 사용하면 안 됩니다!
return (
<div>
<h3>소개</h3>
<div>{bio}</div>
</div>
);
}
const UserProfilePage = () => {
// 만약 공격자가 bio에 다음과 같은 악성 스크립트를 입력했다면?
const bio =
'안녕하세요! 저는 웹 개발자입니다. <script>alert("XSS 공격 성공! 쿠키: " + document.cookie);</script>';
return (
<div>
<UserProfile bio={bio} />
{/* 이 컴포넌트가 렌더링되면, 다른 사용자의 브라우저에서 스크립트가 실행되어 경고창이 뜨고 쿠키 정보가 노출될 수 있습니다. */}
</div>
);
};
export default UserProfilePage;
dangerouslySetInnerHTML を避け、入力は常に{} を通して描画することが、最も基本的で重要な原則です。import DOMPurify from 'dompurify';
function SanitizedHtmlComponent({ dirtyHtml }: { dirtyHtml: string }) {
// HTML 정제 수행
const cleanHtml = DOMPurify.sanitize(dirtyHtml);
// 정제된 안전한 HTML만 렌더링
return <div dangerouslySetInnerHTML={{ __html: cleanHtml }} />;
}mybank.com にログインしているとします。その状態で悪意のある evil.com を訪れた場合、その evil.com には次のようなコードが隠されているかもしれません。<!-- 사용자는 이 이미지를 보지만, 브라우저는 mybank.com으로 요청을 보낸다 -->
<img src="https://mybank.com/transfer?to=hacker&amount=1000000" width="1" height="1" />
<!-- 또는, 자동으로 제출되는 숨겨진 폼 -->
<form id="csrf-form" action="https://mybank.com/change-password" method="POST" style="display:none;">
<input type="hidden" name="newPassword" value="hacked123" />
</form>
<script>document.getElementById('csrf-form').submit();</script>evil.com を読み込むと、ブラウザは mybank.com のmybank.com のサーバーに送ります。mybank.com 側がユーザーの意図した操作か検証しなければ、攻撃者はそのアカウントで送金やパスワード変更などを実行できる可能性があります。X-CSRF-Token などのHTTPヘッダーに含めて送ります。
SameSite 属性に対応し、CSRFの軽減に役立ちます。evil.com から mybank.com への要求など、外部サイトから始まる要求には一切送らないため、強力な防御になります。ただし、外部からリンクで訪れる正常なアクセスでもCookieが送られない場合があります。Strict より少し緩い設定です。リンクのクリック（<a> タグ）や GET のフォーム送信など、安全とされる一部のトップレベルナビゲーションでは、別サイトからの要求でもCookieを送ります。POSTや <img> などによる多くのCSRFを防ぎ、ユーザー体験も大きく損なわないため、既定値として推奨されることが多い設定です。Secure 属性が必須です。埋め込みコンテンツの認証など、サードパーティの文脈で必要な場合に限定して使います。SameSite=Lax または Strict を設定することは、CSRF対策に大きく役立ちます。フロントエンド開発者も、その意味を理解し、適切な設定か確認しましょう。Referer を確認し、許可したドメインから始まった要求か調べます。ただし、ユーザーの設定やプロキシなどで欠落する場合があり、完全な防御ではありません。X-Requested-With など特定のヘッダーを持つ要求だけをサーバーで許可します。同一オリジンポリシーにより、別ドメインからJavaScriptでカスタムヘッダーを付けた要求を送りにくい点を利用します。ただし、CORS設定が誤っていれば回避される可能性があります。Q: 「CSRF攻撃とは何ですか？どう防げますか？」 A: 攻撃の仕組み、CSRFトークンとSameSite Cookieによる対策の原理、フロントエンドの役割を併せて説明する
client_id：事前登録したアプリの識別子。redirect_uri：認可コードを受け取るアプリのアドレス。response_type=code：認可コードを要求する指定。scope：要求する情報の範囲。例は openid profile email。code_challenge：生成したハッシュ値。code_challenge_method=S256：ハッシュアルゴリズムの指定。state：CSRF対策のランダムな文字列。任意ですが推奨されます。redirect_uri に戻されます。state が含まれます。HttpOnly、Secure、SameSite=Strict（またはLax）のCookieに保存し、JavaScriptから直接アクセスできなくするのが最も安全です。難しい場合はメモリに置き、別の安全策も検討します。Authorization ヘッダーに入れます。例は Authorization: Bearer YOUR_ACCESS_TOKEN です。
// Zustand 스토어 예시
import create from 'zustand';
interface AuthState {
accessToken: string | null;
setAccessToken: (token: string | null) => void;
}
const useAuthStore = create<AuthState>((set) => ({
accessToken: null,
setAccessToken: (token) => set({ accessToken: token }),
}));
// 로그인 성공 후 토큰 저장
// const { setAccessToken } = useAuthStore.getState();
// setAccessToken(receivedAccessToken);
// API 요청 시 토큰 사용
// const accessToken = useAuthStore((state) => state.accessToken);
// axios.get('/api/protected', { headers: { Authorization: `Bearer ${accessToken}` } });HttpOnly、Secure、SameSite=Strict（または Lax）を付けたCookieに保存します。HttpOnly によりクライアントのJavaScriptからアクセスできず、XSSでCookieを直接盗むことを防げます。Secure はHTTPSでのみ送信させ、SameSite はCSRFを防ぎます。/api/refresh_token などの更新用エンドポイントを呼ぶだけです。ブラウザがRefresh Token入りのHttpOnly Cookieを自動送信し、バックエンドが読み取って新しいAccess Tokenを返します。// 백엔드에서 로그인 성공 또는 토큰 발급 시
res.cookie('refreshToken', receivedRefreshToken, {
httpOnly: true, // JavaScript 접근 불가
secure: true, // HTTPS에서만 전송
sameSite: 'lax', // 또는 'strict'
maxAge: 7 * 24 * 60 * 60 * 1000 // 예: 7일 유효기간
});
res.json({ accessToken: receivedAccessToken }); // Access Token은 JSON 응답으로 전달Q: 「OAuth 2.0の認可コードフローで、フロントエンドは何を担当しますか？」または「Access Tokenはどこに保存すると安全ですか？」 A: 各段階の役割と、保存先ごとの安全性（LocalStorageのXSSへの弱さ、HttpOnly CookieのCSRF対策上の利点など）を明確に説明する
npm audit、Snyk、Dependabotなどで既知の脆弱性を確認し、定期的に更新します。不要な依存は削除します。<script> に async や defer を付け、ページの描画を妨げないようにします。本当に必要なときだけ動的に読み込む方法も検討します。<script> や <link> の integrity 属性に指定します。ブラウザは取得後にハッシュを比較し、内容が変わっていれば読み込みを遮断します。
<script src="https://example.com/library.js"
integrity="sha384-oqVuAfXRKap7fdgcCY5uykM6+R9GqQ8K/uxy9rx7HNQlGYl1kPzQho1wx4JwY8w/"
crossorigin="anonymous"></script>dangerouslySetInnerHTML には細心の注意が必要です。次回は、開発の生産性と品質を高める開発者ツールとテストを学びます。React DevTools、Jest、React Testing Library、Storybookなどを見ていきましょう。