建築上の優先事項としての安全性
のようなイベント管理プラットフォームでは、 イベントをプレイする、 安全性は二次的な側面ではなく、基本的な要件です。ユーザーは 個人データ、支払い情報、文書、プライベートなコミュニケーションを共有します。 このデータを保護するには、認証を含む多層的なアプローチが必要です。 承認、転送中および保存中のデータの保護、および主要なデータに対する防御 Web 攻撃のカテゴリ。
この記事でわかること
- HttpOnly Cookie を使用した JWT 認証アーキテクチャ
- ステートレスなセッション管理
- ローテーションによるトークン更新メカニズム
- 電子メール検証ワークフロー
- RBAC (役割ベースのアクセス制御) システム
- OWASP セキュリティ ヘッダーと保護
- レート制限と入力検証
HttpOnly Cookie を使用した JWT
認証設計における最も重要な選択は、 JWT トークンを localStorage に保存しないでください。それが練習であるにもかかわらず、 SPA (シングル ページ アプリケーション) でより広く普及しているため、localStorage は脆弱です XSS 攻撃: ページのコンテキストで実行できる JavaScript スクリプト トークンを読み取って悪意のあるサーバーに送信する可能性があります。
イベントをプレイする 代わりに使用してください HTTP のみの Cookie、JavaScript ではアクセスできません。 これらは、各 HTTP リクエストとともにブラウザによって正しいドメインに自動的に送信されます。
// Creazione del cookie HttpOnly con il token JWT
ResponseCookie accessCookie = ResponseCookie.from("access_token", accessToken)
.httpOnly(true) // Non accessibile da JavaScript
.secure(true) // Solo HTTPS
.sameSite("Strict") // Protezione CSRF
.path("/") // Valido per tutto il dominio
.maxAge(Duration.ofMinutes(15)) // Scadenza breve
.build();
ResponseCookie refreshCookie = ResponseCookie.from("refresh_token", refreshToken)
.httpOnly(true)
.secure(true)
.sameSite("Strict")
.path("/api/v1/auth/refresh") // Solo per il refresh endpoint
.maxAge(Duration.ofDays(7)) // Scadenza lunga
.build();セキュリティ: localStorage と HttpOnly Cookie の比較
JWT トークンを localStorage 彼らをあらゆる脆弱性にさらす
XSS はアプリケーションまたはサードパーティのライブラリに存在します。単一の悪意のあるスクリプト
トークンを盗んでユーザーになりすますことができます。 HttpOnly Cookie を完全に排除
ブラウザはトークンを外部に公開せずに処理するため、この攻撃ベクトルが有効になります。
JavaScript コード。
ステートレスセッション管理
認証アーキテクチャは完全に ステートレス: サーバー メモリ内にセッションを保持しません。各 HTTP リクエストにはすべての情報が含まれています ユーザーの認証と認可に必要な情報で、JWT トークンにエンコードされます。
このアプローチには、スケーラビリティに関して大きな利点があります。 セッションレプリケーションを必要とせずに、複数のサーバーインスタンスに負荷を分散します。 またはスティッキーセッション。各インスタンスは、次のことを確認することで JWT トークンを個別に検証できます。 デジタル署名。
// Esempio di payload JWT (i dati sensibili NON sono inclusi)
{
"sub": "user-uuid-here",
"email": "utente@example.com",
"roles": ["USER", "ORGANIZER"],
"iat": 1709294400,
"exp": 1709295300,
"jti": "unique-token-id"
}ローテーションによるトークンのリフレッシュ
システムは次のメカニズムを実装します。 リフレッシュトークンのローテーション 妨げるもの トークン再利用攻撃。リフレッシュトークンを使用して取得する場合 新しいアクセス トークンが発行されると、古いリフレッシュ トークンが無効になり、新しいリフレッシュ トークンが発行されます。
FLUSSO REFRESH TOKEN
1. Client invia richiesta con access_token scaduto
→ Server risponde 401 Unauthorized
2. Client chiama POST /api/v1/auth/refresh
→ Il refresh_token viene inviato automaticamente via cookie
3. Server verifica il refresh_token:
a. Token valido e non nella blacklist?
b. Token non ancora utilizzato per un refresh?
c. Utente ancora attivo nel sistema?
4. Se tutto è valido:
→ Genera nuovo access_token (15 min)
→ Genera nuovo refresh_token (7 giorni)
→ Invalida il vecchio refresh_token (blacklist)
→ Imposta nuovi cookie HttpOnly
5. Se il refresh_token è già stato utilizzato:
→ ALERT: possibile furto token
→ Invalida TUTTI i refresh token dell'utente
→ L'utente deve riautenticarsiローテーションにより、各リフレッシュ トークンは 1 回だけ使用できるようになります。もし 攻撃者がリフレッシュ トークンを盗んで使用すると、正当な所有者が受け取ることになります。 次回の更新時にエラーが発生し、侵害の可能性を示します。
メールの確認
登録にはワンタイムトークンによるメールアドレス認証が必要です ユーザーの受信箱に送信されます。トークンの有効期限は 24 時間です。 1回のみ使用してください。認証されるまで、アカウントの機能は制限されています。
役割ベースのアクセス制御 (RBAC)
RBAC システムの イベントをプレイする 2 つのレベルで動作します。 システムの役割 そして私 イベントごとの役割.
システムの役割
- 管理者: すべてのプラットフォーム機能、ユーザー管理、コンテンツ管理、管理パネルへのアクセスへの完全なアクセス
- ユーザー： イベントの作成と参加、プロフィールの管理、すべての基本機能の使用ができる標準ユーザー
- 主催者: 高度な分析、外部統合、大規模イベント管理などのプレミアム機能へのアクセスによる役割の拡大
- モデレータ： 公開コンテンツの管理、レポートの管理、プラットフォーム ポリシーの適用が可能
メソッドレベルのセキュリティ
HTTP フィルターに加えて、システムは以下を使用します。 @PreAuthorize Spring Security の
個々のコントローラー メソッドを保護し、アクセス許可をきめ細かく制御します。
@RestController
@RequestMapping("/api/v1/eventi")
public class EventoController {
@PostMapping
@PreAuthorize("hasAnyRole('USER', 'ORGANIZER')")
public ResponseEntity<EventoResponse> createEvento(
@Valid @RequestBody CreateEventoRequest request) {
// Solo utenti con ruolo USER o ORGANIZER
}
@DeleteMapping("/{id}")
@PreAuthorize("@eventoSecurityService.isOrganizer(#id, authentication)")
public ResponseEntity<Void> deleteEvento(@PathVariable Long id) {
// Solo l'organizzatore dell'evento specifico
}
@GetMapping("/admin/all")
@PreAuthorize("hasRole('ADMIN')")
public ResponseEntity<Page<EventoResponse>> getAllEventi(Pageable pageable) {
// Solo amministratori
}
}セキュリティヘッダー
プラットフォームは、保護するための包括的なセキュリティ HTTP ヘッダーのセットを実装しています。 Web 攻撃の主要なカテゴリに対抗します。
HEADER DI SICUREZZA
Content-Security-Policy:
default-src 'self';
script-src 'self';
style-src 'self' 'unsafe-inline';
img-src 'self' data: https:;
connect-src 'self' https://api.stripe.com;
X-Frame-Options: DENY
→ Previene clickjacking (embedding in iframe)
X-Content-Type-Options: nosniff
→ Previene MIME type sniffing
Strict-Transport-Security: max-age=31536000; includeSubDomains
→ Forza HTTPS per un anno
Referrer-Policy: strict-origin-when-cross-origin
→ Limita le informazioni nel referrer header
Set-Cookie: SameSite=Strict
→ Protezione CSRF nativa del browserBucket4j によるレート制限
悪用、ブルートフォース攻撃、DDoS を防ぐために、システムには次の機能が実装されています。 レート制限 図書館を使って バケット4j、トークン バケット アルゴリズムに基づいています。
- 一般的な API: 認証されたユーザーごとに 1 分あたり 100 リクエスト
- ログインエンドポイント: IP ごとに 1 分あたり 5 回の試行 (ブルート フォース保護)
- 記録エンドポイント: IP ごとに 1 分あたり 3 リクエスト
- エンドポイントを更新します: ユーザーあたり 1 分あたり 10 リクエスト
ベスト プラクティス: 差別化されたレート制限
すべてのエンドポイントが同じセキュリティ ニーズを持っているわけではありません。認証エンドポイント データ読み取り API よりもはるかに厳しい制限が必要です。分割払い 制限はリスクに比例する必要があります。エンドポイントの機密性が高くなるほど、 制限は低くする必要があります。 Bucket4j を使用すると、さまざまな制限を設定できます エンドポイントグループごと。
BCrypt によるパスワードのハッシュ化
ユーザーのパスワードはハッシュ化されます BCクリプト コスト要因を使用する 12 の場合、ハッシュ操作ごとに約 250 ミリ秒が保証されます。これは計算的に次のようになります ブルートフォース攻撃は、データベースが侵害された場合でもコストがかかります。
入力の検証
システムに入力される各データは、次を使用して検証されます。 ジャカルタ Bean の検証
(注釈 @NotNull, @Size, @Email,
@Pattern) ビジネス ロジックに到達する前に。 DTO は次のように機能します。
第 1 レベルの防御、ドメイン内の値オブジェクトは第 2 レベルを提供します。
セマンティック検証の。
OWASP トップ 10 コンプライアンス
このシステムは以下を考慮して設計されました。 OWASP トップ 10 Web アプリケーションにとって最も重大な脆弱性。
- A01 - 壊れたアクセス制御: マルチレベル RBAC、リソース所有者の検証、最小特権の原則
- A02 - 暗号化の失敗: 強制HTTPS、パスワード用のBCrypt、保存時の機密データの暗号化
- A03 - 注射: JPA/Hibernate によるクエリのパラメータ化、自動入力エスケープ
- A04 - 安全でない設計: 脅威モデル化されたアーキテクチャ、プロジェクトの開始時から設計によるセキュリティ
- A05 - セキュリティの設定ミス: 完全なセキュリティ ヘッダー、環境ごとに異なる構成 (開発、ステージング、本番)
- A07 - 認証の失敗: JWT HttpOnly、リフレッシュローテーション、試行失敗後のロックアウト
ログアウト用のトークン ブラックリスト
ログアウトすると、ユーザーのトークンはすぐに無効になります。 ブラックリスト。 認証された各リクエストは、続行する前にトークンがブラックリストに載っていないことを確認します。 ブラックリストは、最大有効期間に等しい TTL を持つメモリ内キャッシュを使用して実装されます。 トークンの無制限の増加を回避します。
保護の概要
- SameSite=Strict を使用した HttpOnly Cookie の JWT
- 盗難検出によるリフレッシュトークンローテーション
- 2 レベルの RBAC (システムおよびイベントごと)
- 完全なセキュリティ ヘッダー (CSP、HSTS、X-Frame-Options)
- Bucket4j による差別化されたレート制限
- コスト係数 12 の BCrypt
- 2 レベルの入力検証 (DTO + 値オブジェクト)
- 即時ログアウト用のトークン ブラックリスト
セキュリティ関連のソース コードは次の場所から入手できます。 GitHub。 次の記事では、イベントと参加者の管理をさらに詳しく掘り下げ、 REST API、ステートマシン、および招待システム イベントをプレイする.