【まとめ】なぜ重要な処理はサーバー側に置くべきなのか
章: 1章
技術タグ: DevTools fetch GET JavaScript JSON PHP サーバー セキュリティ
今回やること
ここまで、おみくじアプリを使ってフロントエンドとバックエンドの役割を学んできました。
第1話では、JavaScriptだけでおみくじアプリを作りました。
第2話では、DevToolsを使って、ブラウザ側の処理が見えること、そして一部は改ざんできることを体験しました。
第3話では、抽選ロジックをPHP側に移しました。
第4話では、NetworkタブでJavaScriptとPHPの通信を確認しました。
今回は、この流れを一度整理します。
作る ↓ 壊す ↓ 覗く ↓ 守る ↓ 理解する
この流れを押さえると、なぜ重要な処理をサーバー側に置くべきなのかが見えてきます。
第1話:JavaScriptだけでおみくじを作った
最初は、HTML・CSS・JavaScriptだけでおみくじアプリを作りました。
ボタンを押すと、配列の中からランダムに結果を選び、画面に表示する仕組みです。
ボタンを押す ↓ JavaScriptがランダムな番号を作る ↓ 配列から結果を選ぶ ↓ 画面に表示する
この時点では、Webアプリの基本を体験できました。
- HTMLで画面の骨組みを作る
- CSSで見た目を整える
- JavaScriptでボタンの動きを作る
- 配列からランダムに値を選ぶ
- DOMを書き換えて画面に表示する
ここまでは、かなり良い入口です。
小さなアプリを作ることで、JavaScriptがブラウザ上で画面を動かす役割を持っていることがわかりました。
第2話:DevToolsでフロントエンドの限界を見た
次に、DevToolsを使って、おみくじアプリの中身を見ました。
Elementsタブでは、HTML構造を確認できました。
Consoleでは、JavaScriptをその場で実行できました。
そして、画面上の結果を 大吉 に書き換えることもできました。
document.getElementById('result').textContent = '大吉';
ここで大事なのは、次の事実です。
ブラウザ側の中身はユーザーに見える ブラウザ側の表示はユーザー側で一部書き換えられる ブラウザ側の処理は信用しすぎてはいけない
もちろん、画面を書き換えたからといって、サーバー上のファイルが変わるわけではありません。
しかし、フロントエンド側だけで重要な判定をしている場合、そこを狙われる危険があります。
第3話:抽選ロジックをPHP側に移した
第3話では、おみくじの抽選ロジックをJavaScriptからPHPへ移しました。
JavaScriptは結果を決める係ではなく、PHPへ結果を取りに行く係になりました。
| 担当 | 役割 |
|---|---|
| JavaScript | ボタン操作を受け取り、PHPへ通信し、返ってきた結果を画面に表示する |
| PHP | サーバー側でおみくじ結果を決め、JSONで返す |
この変更によって、抽選ロジックをブラウザ側のJavaScriptに丸出しで置く構成から一歩進みました。
ブラウザ側で抽選する ↓ サーバー側で抽選する
これは、フロントエンドとバックエンドの責務分担の入口です。
画面操作や表示はJavaScript、重要な処理はPHP。
この切り分けが、Webシステム開発ではかなり大事になります。
第4話:Networkタブで通信を見た
第4話では、DevToolsのNetworkタブを使って、JavaScriptとPHPの通信を確認しました。
ボタンを押すと、JavaScriptが omikuji.php に通信していました。
const response = await fetch('omikuji.php');
PHPは、おみくじ結果をJSONで返していました。
{"fortune":"大吉"}
JavaScriptは、そのJSONを読み取って画面に表示しました。
const data = await response.json(); resultText.textContent = data.fortune;
Networkタブを見ることで、画面の裏でブラウザとサーバーが会話していることを確認できました。
Webアプリは、画面だけでなく通信を見ると一気に理解が進みます。
なぜ重要な処理をサーバー側に置くのか
ここまでの流れから、重要な処理をサーバー側に置く理由が見えてきます。
理由はシンプルです。
ブラウザ側のコードは、ユーザーに見えるから
JavaScriptは便利です。
画面を動かしたり、入力補助をしたり、非同期通信をしたりできます。
しかし、ブラウザ側で動く以上、ユーザーに見られる前提で考える必要があります。
そのため、以下のような処理はブラウザ側だけに任せるべきではありません。
- 抽選結果の最終決定
- 料金計算の最終決定
- ログイン判定
- 権限チェック
- ポイント付与
- クーポン発行
- データ保存前の最終チェック
これらは、不正されると困る処理です。
だから、最終判断はサーバー側で行う必要があります。
フロントエンドでやること・サーバー側でやること
ここで、役割を整理します。
| 場所 | 向いている処理 | 注意点 |
|---|---|---|
| フロントエンド | 画面表示、ボタン操作、入力補助、簡単な見た目の切り替え | ユーザーに見える前提で考える |
| バックエンド | 重要な判定、データ保存、認証、権限チェック、メール送信 | ユーザーから直接見えにくい場所で最終判断する |
フロントエンドが不要という話ではありません。
むしろ、JavaScriptはWebアプリの使いやすさを大きく上げます。
ただし、JavaScriptに任せるべきことと、サーバー側で守るべきことを分ける必要があります。
フロントエンド:ユーザー体験を良くする バックエンド:重要な処理を守る
今回のおみくじで見る責務分担
今回のおみくじアプリでは、責務分担はこうなりました。
| 処理 | 担当 |
|---|---|
| 画面を表示する | HTML / CSS |
| ボタンを押したことを検知する | JavaScript |
| PHPへ通信する | JavaScript fetch |
| おみくじ結果を決める | PHP |
| 結果をJSONで返す | PHP |
| 返ってきた結果を画面に表示する | JavaScript |
これを見ると、Webアプリは複数の技術が役割分担して動いていることがわかります。
HTML、CSS、JavaScript、PHPはバラバラの知識ではありません。
1つの流れの中でつながっています。
ただし、PHPに移せば完全に安全というわけではない
ここも大事です。
抽選ロジックをPHP側に移したからといって、それだけで本格的なキャンペーンシステムが完成するわけではありません。
たとえば、本当に景品が絡む抽選なら、さらに次のような対策が必要になります。
- 誰が引いたのかを記録する
- 同じ人が何度も引けないようにする
- 抽選結果をデータベースに保存する
- 不正な連続アクセスを防ぐ
- サーバー側で最終判定する
- ログを残す
今回の目的は、いきなり完璧な抽選システムを作ることではありません。
まずは、重要な処理をフロントエンドだけに置かないという考え方を理解することです。
この章で得た一番大事な感覚
第1章で一番大事なのは、次の感覚です。
画面に表示されているものだけを信用しない ブラウザ側の処理だけを信用しない 重要な処理はサーバー側で最終判断する
これは、今後フォームやログイン、データベース保存を学ぶ時にもそのまま使います。
たとえば、お問い合わせフォームでも同じです。
JavaScriptで空欄チェックをしていても、それだけでは不十分です。
なぜなら、JavaScriptは無効化されたり、DevToolsで書き換えられたりする可能性があるからです。
だから、サーバー側でも必ずチェックする必要があります。
作る、壊す、覗く、守る
この章では、以下の流れで学びました。
作る:JavaScriptだけでおみくじを作る 壊す:DevToolsで結果を書き換える 覗く:Networkで通信を見る 守る:抽選ロジックをPHP側に移す
この順番が大事です。
最初から正解だけを見ても、なぜそれが必要なのかは理解しにくいです。
一度作る。一度壊す。裏側を見る。それから守る。
この流れで学ぶと、技術が単なる暗記ではなく、必要性とセットで理解できます。
ここまでの到達地点
ここまでで、次のことができるようになりました。
- JavaScriptで小さなアプリを作れる
- DevToolsでHTMLやConsoleを確認できる
- ブラウザ側の表示を一時的に書き換えられることを知った
- PHPでJSONを返せる
- JavaScriptのfetchでPHPへ通信できる
- Networkタブで通信を確認できる
- フロントエンドとバックエンドの役割分担を少し理解できた
これは、Webシステム開発の入口としてかなり大事な一歩です。
次はフォーム編へ進みます
次章では、お問い合わせフォームを作ります。
フォームは、Web開発の基礎がかなり詰まっています。
- HTMLフォーム
- 入力チェック
- POST通信
- PHPでの受け取り
- XSS
- エスケープ
- データベース保存
- 二重送信
- PRGパターン
おみくじ編では、ブラウザ側の処理を信用しすぎてはいけないことを学びました。
フォーム編では、その考え方がさらに重要になります。
なぜなら、フォームではユーザーが自由にデータを送ってくるからです。
次回予告
次回からは、お問い合わせフォーム編に入ります。
まずはHTMLでシンプルなフォームを作り、JavaScriptで空欄チェックをしてみます。
次回のテーマは、以下です。
【HTMLフォーム入門】お問い合わせフォームを作って入力チェックの入口を学ぶ
ここからは、ユーザーが送ってくるデータと向き合います。
ブラウザ側だけでは守れないという感覚を持ったまま、フォーム処理の世界に進みます。