Web アプリ開発の基本から応用まで、クイズで学ぼう！
Q1 : WebSocketとHTTPの主な違いはどれか？ WebSocketはコネクションを確立後に双方向のリアルタイム通信が可能で、サーバーからクライアントへ任意のタイミングでデータ送信できる WebSocketは常にHTTP/2を使用するため高速である HTTPは状態を維持するため常にコネクションを持ち続ける WebSocketはブラウザではサポートされていない
WebSocketは初回にHTTPベースのハンドシェイクを行った後、TCPソケットを用いた持続的な双方向通信チャネルを確立します。これによりサーバーはクライアントに任意のタイミングでメッセージを送信でき、チャットや通知等のリアルタイム性を要する用途に適しています。HTTPはリクエスト/レスポンスモデルであり、必ずしも常時接続を維持しません。
Q2 : JWT（JSON Web Token）をクライアント側に保存する際の一般的なリスクは何か？ トークンが長すぎてブラウザが対応できない XSSによりトークンが盗まれて不正利用されるリスクがある JWTは暗号化されているため盗まれても安全である JWTは常にサーバー側で無効化できる
JWTは署名されて改ざん検出が可能ですが、内容が必ずしも暗号化されているわけではありません（署名は検証用）。したがってクライアント側に保存すると、特にlocalStorageやsessionStorageに保存した場合、XSS攻撃でトークンが盗まれ、なりすましに使われるリスクがあります。CSRF対策や短い有効期限、適切な保存場所（HttpOnlyクッキー等）の検討が重要です。
Q3 : HTTPのキャッシュ制御で、再検証を行わずにレスポンスを一定時間そのまま使わせたい場合に使うヘッダーはどれか？ Cache-Control: no-store Cache-Control: max-age=<秒> ETag Vary
Cache-Control: max-age=はレスポンスの有効期限を秒単位で指定し、指定時間内は再検証せずにキャッシュをそのまま利用させるという指示です。ETagはエンティティタグによる再検証（条件付きGET）を行うための仕組み、no-storeはキャッシュを保存させない、Varyはキャッシュのバリエーション制御用です。
Q4 : データベーストランザクションのACID特性における「隔離性（Isolation）」の説明として最も適切なのはどれか？ トランザクションの変更は直ちに永続化されること トランザクション中の操作は他のトランザクションから独立して見えること（干渉がないこと） トランザクションが必ずコミットされること トランザクションのパフォーマンスが最適化されること
トランザクションのACIDのうち「隔離性（Isolation）」は、複数の同時実行トランザクションが互いに干渉しないように動作することを指します。具体的には未コミットの変更が他トランザクションから見えないなどの保証により、ダーティリードやファントムリード等の問題を防ぎます。選択肢のうち隔離性の説明に該当するのは干渉のない独立性であり、パフォーマンス最適化は該当しません。
Q5 : RESTにおけるGETメソッドの主な特性は？ リソースの取得を行い、安全で副作用がない（読み取り専用） サーバー上に新しいリソースを作成する 既存リソースを部分的に更新する 既存リソースを完全に置き換える
GETはリソースの取得を目的としたHTTPメソッドであり、一般に安全（副作用を持たない）で冪等性が期待される読み取り専用操作です。安全性とはリクエストを複数回繰り返しても状態が変わらないこと、冪等性とは同一の操作を何度行っても結果が同じであることを意味します。POSTは作成、PATCHは部分更新、PUTは置換に使われます。
Q6 : CORS（Cross-Origin Resource Sharing）の主な目的はどれか？ サーバー間でのTLS証明書の共有を行う ブラウザが異なるオリジン間で安全にリソースを共有できるようにする HTTPリクエストの圧縮方式を定義する クッキーの暗号化を提供する
CORSはブラウザが異なるオリジン（プロトコル・ドメイン・ポートが異なる場合）からのリソースアクセスを制御する仕組みです。サーバーは特定のOriginを許可するレスポンスヘッダー（Access-Control-Allow-Origin等）を返すことで、ブラウザに対して安全にクロスオリジンリクエストを許可できます。TLSや圧縮、クッキー暗号化とは目的が異なります。
Q7 : CSRF（クロスサイトリクエストフォージェリ）対策として一般的に推奨されるのはどれか？ 送信する全てのPOSTをTLSで暗号化する APIキーをURLに含める リクエストに一意なトークン（CSRFトークン）を含めて検証する Refererヘッダーを常に無視する
CSRFはユーザーの認証されたセッションを悪用して意図しない操作を実行させる攻撃です。対策としてはフォームや状態変更リクエストに一意のCSRFトークンを付与し、サーバー側で検証する方法が一般的で有効です。TLSは重要だがCSRF自体の防御ではなく、APIキーをURLに含めると漏洩リスクが高く、Refererを無視するのは逆効果です。
Q8 : SQLインジェクションを防ぐ安全な実装方法として最も適切なのはどれか？ ユーザー入力を全てエンコードしてからSQLに連結する 入力の長さチェックのみを行う クエリ文字列の特殊文字を単純にエスケープする プリペアドステートメント（パラメータ化クエリ）を使用する
SQLインジェクションはユーザー入力が直接SQL文として解釈されることで発生します。最も効果的な対策はプリペアドステートメントやパラメータ化クエリを使用し、入力値をSQL構文とは分離してバインドすることです。単なる長さチェックやエスケープは不完全で、エンコードも万能ではありません。プリペアドステートメントは多くのDBドライバで推奨される安全策です。
まとめ
いかがでしたか？ 今回はWebアプリ開発クイズをお送りしました。
今回はWebアプリ開発クイズを出題しました。
ぜひ、ほかのクイズにも挑戦してみてください！
