API を書き、すべてが機能し、テストが合格し、フロントエンドがエンドポイントを引っ張ります。美しい。そして誰かがトークンを公開リポジトリに流し、ボットがサーバーを毎秒10,000リクエストで攻撃し始め、インターンが誤ってAPIを介して本番データベースを削除します。
APIセキュリティの世界へようこそ。すべてが支えられている3つの主要な柱と、開発者が最も頻繁につまずく場所を見てみましょう。
🎫 1. トークン：デジタルパス
これは何ですか？なぜですか？
トークンは、サーバーに「私は自分が誰であるかを伝える」という文字列です。トークンがない場合、保護されたAPIへのリクエストはすべて冷たい401 Unauthorizedを受け取ります。
最も人気のあるスキーム：
API Key — 見出しまたはクエリパラメータの単純なキー。便利ですが、粗いです。
JWT (JSON Web Token) — ペイロード、署名、有効期間を持つ自己充足型トークン。
OAuth 2.0 Access Token — 認証サーバーを介して発行され、サードパーティのアプリケーションに最適です。
どこにコーシャチャトがありますか？
❌ コード内のトークンの保存
ジャンルの定番。開発者はソースコードに直接const API_KEY = "sk-live-abc123..."を書き込みます。GitHubにプッシュします。ボットは30秒でキーを見つけます。こんにちは、リーク。
// ❌ これは敵だけが自分自身に対して行うことですconst API_KEY = "sk-live-abc123def456";
// ✅環境変数はすべてAPI_KEY = process.env.API_KEY;❌ 有効期限のないトークン
トークンを発行すると、トークンは永遠に存在します。トークンが盗まれた場合、攻撃者は無期限にアクセスできます。expなしのJWTは、再発行できないアパートの鍵のようなものです。
❌ URL を介したトークンの転送
トークンがクエリパラメータ（?token=abc123）で飛行すると、サーバーログ、ブラウザ履歴、分析に格納されます。常にヘッダー Authorization を使用してください。
Authorization: Bearer eyJhbGciOiJIUzI1NiIs...
❌ 回転なし
同じキーが何年も使用されています。ルールは簡単です。キーを定期的に変更し、access/refreshトークンのペアを使用します。
🚦 2. レート制限：API のブレーキ
これは何ですか？なぜですか？
レート制限は、時間単位あたりのリクエスト数の制限です。レート制限がなければ、攻撃的なクライアント（またはボット）が1つだけでサービス全体を停止させる可能性があります。
どこにコーシャチャトがありますか？
❌ レート制限が全く設定されていない
驚くべきことに、多くのAPIは制限なしで本番環境にリリースされます。トラフィックが少ない間は問題ありません。しかし、最初のDDoS攻撃または無限ループのある不正なスクリプトで、サーバーがダウンします。
❌ IP のみの制限
論理的に聞こえますが、1 つの IP の背後にオフィス全体または VPN が隠れている可能性があります。攻撃者は、何千ものアドレスにリクエストを分散させることができます。トークン/ユーザーごとに制限することをお勧めします。
# Pythondef check_rate_limit (user_id) での Redis の例:
key = f"rate:{user_id}"
current = redis.incr(key)
if current == 1:
redis.expire(key, 60) # ウィンドウ — 60 秒
if current > 100:
raise RateLimitExceeded()❌ 有益な回答はありません
クライアントが制限に達したとき、何が起こったのかを理解する必要があります。429 Too Many Requestsと便利なヘッダーを返します。
HTTP/1.1 429 Too Many Requests
Retry-After: 30
X-RateLimit-Limit: 100
X-RateLimit-Remaining: 0
X-RateLimit-Reset: 1700000000
❌ すべてのエンドポイントに同じ制限を適用する
GET /users と POST /payments のリクエストは、負荷と重要度の点でまったく異なる操作です。重い操作や機密性の高い操作（支払い、メールの送信、レポートの生成）には、より厳しい制限を設ける必要があります。
👑 3. アクセス権：すべてが同じではない
これは何ですか？なぜですか？
ユーザーが認証されている場合でも（ユーザーが誰であるかを知っている場合でも）、ユーザーが何でもできるわけではありません。承認は、「あなたが許可されているのは何ですか？」という質問に答えます。
どこにコーシャチャトがありますか？
❌ フロントエンドでのみ権限を確認
「削除」ボタンは、通常のユーザーのUIでは非表示になっていますか？素晴らしい。しかし、curlを介して直接DELETE /api/users/42を送信すると、サーバーはリクエストを実行します。権限の確認はバックエンドで行う必要があります。常に。
// ❌ フロントエンド「保護」
{role === 'admin' && <button onClick={deleteUser}>Удалить</button>}
// ✅ バックエンドチェックは必須です
app.delete('/api/users/:id', (req, res) => {
if (req.user.role !== 'admin') {
return res.status(403).json({ error: 'Forbidden' });
}
// ...削除
});❌ IDOR — Insecure Direct Object Reference
最も一般的な脆弱性の1つです。ユーザーは GET /api/orders/123 をリクエストし、注文を確認します。123 を 124 に変更すると、他のユーザーのものが表示されます。サーバーは、リソースが現在のユーザーに属しているかどうかを確認しません。
// ❌所有者を確認せずにURLからのIDを信頼する
app.get('/api/orders/:id', async (req, res) => {
const order = await Order.findById(req.params.id);
res.json(order); // 誰の注文でも
});
// ✅ 所有者で絞り込む
app.get('/api/orders/:id', async (req, res) => {
const order = await Order.findOne({
_id: req.params.id,
userId: req.user.id // 自分の注文のみ
});
if (!order) return res.status(404).json({ error: 'Not found' });
res.json(order);
});❌ トークンのスコープが広すぎる
OAuth を使用すると、制限された権限（スコープ）を持つトークンを発行できます。しかし、開発者はしばしばscope: *を要求します。つまり、すべてに完全にアクセスできます。このようなトークンが漏洩した場合、最大限の影響が生じます。最小特権の原則：特定のタスクに必要な権限を正確に付与します。
❌役割の分離がない
ユーザーには、「認証済み」と「未認証」の2種類があります。必要なものは：管理者、マネージャー、ユーザー、読み取り専用、サービス。適切なロールモデルは、過剰なエンジニアリングではなく、必要性です。
🚀 もっと深く知りたいですか？
プログラミングの道を歩み始めたばかりの方や、実践的なスキルを磨きたい方は、ぜひ試してみてください。 コディックこのアプリでは、プログラミングを実践を通じて学ぶことができます。単に理論を読むだけでなく、すぐにコードを書いて問題を解決することができます。
そして、私たちの Telegramコミュニティ — 開発、タスク分析、新しい資料に関する役立つ投稿が定期的に公開されています。すでに2000人以上の開発者がいます！
API がニュースに載るような開発者にならないでください。今すぐチェックリストを確認してください。 🔒