ファイルアップロード機能のセキュリティ対策｜業務システムで必須の設計ポイントを解説

「契約書をPDFで登録したい」
「ExcelやCSVを業務システムへアップロードしたい」
「ユーザーが画像を登録できるようにしたい」

業務システムでは、ファイルアップロード機能が必要になる場面が多くあります。

例えば、

• 契約書
• 見積書
• 請求書
• Excel
• CSV
• PDF
• 商品画像
• 本人確認書類
• 作業報告書
• 各種申請資料

などです。

しかし、ファイルアップロードは単に「ファイルを選択してサーバーへ保存する」だけでは安全な機能になりません。

外部から任意のファイルを受け取るという性質上、設計を誤ると、

• 不正なプログラムをアップロードされる
• マルウェアを保存される
• 大容量ファイルによってサーバーへ負荷をかけられる
• 本来見られないファイルを閲覧される
• ファイル名を悪用される
• 危険なHTMLやSVGを実行される
• ストレージ容量を大量に消費される

といった問題につながる可能性があります。

結論からいうと、業務システムのファイルアップロードでは、

「アップロードできるファイルを制限する」「安全な場所へ保存する」「閲覧権限を確認する」

という3つを中心に、複数の対策を組み合わせることが重要です。

この記事では、ファイルアップロード機能にどのようなリスクがあるのか、業務システムではどのようなセキュリティ対策を行えばよいのかを具体的に解説します。

ファイルアップロード機能とは

ファイルアップロード機能とは、利用者のPCやスマートフォンにあるファイルをWebシステムへ登録する機能です。

例えば顧客管理システムで、

顧客詳細画面
↓
契約書を選択
↓
アップロード
↓
顧客情報に紐づけて保存

という機能があります。

操作自体は単純ですが、システム側から見ると、

「ユーザーが作成した任意のデータをサーバーへ送信できる機能」

です。

そのため、通常のテキスト入力フォームとは異なるセキュリティ対策が必要になります。

ファイルアップロード機能にはどのような危険がある？

まず、代表的なリスクを整理しておきましょう。

不正な実行ファイルをアップロードされる

例えば、本来画像だけを登録する機能なのに、

• PHP
• JavaScript
• HTML
• 実行形式ファイル

などをアップロードできる状態になっていると問題です。

特に、アップロードしたファイルがWebサーバー上でそのまま実行可能な場所へ保存される設計は危険です。

「アップロードされたファイルは信用しない」

という前提で設計する必要があります。

ファイル名を悪用される

利用者が付けたファイル名をそのままサーバー上のファイル名として利用すると、予期しない問題につながる可能性があります。

例えば、

../../../example.txt

のようにパスを意識した文字列が含まれているケースです。

適切な処理を行わず保存パスを組み立てると、本来想定していない場所へアクセスする脆弱性につながる可能性があります。

そのため、利用者が入力したファイル名をそのまま内部保存名として利用しない設計が基本です。

マルウェアをアップロードされる

PDF、Word、Excelなどの一般的な文書ファイルであっても、安全とは限りません。

悪意のあるファイルがアップロードされ、それを別の社員がダウンロードして開くことで被害につながる可能性があります。

ファイルを社内で共有するシステムでは特に注意が必要です。

大容量ファイルを大量に送信される

アップロードサイズを制限していない場合、

500MB
1GB
5GB

といった大きなファイルを送信される可能性があります。

さらに何度もアップロードされれば、

• サーバーメモリ
• CPU
• 通信量
• ストレージ容量

を大量に消費します。

意図的な攻撃でなくても、社員が誤って巨大な動画ファイルをアップロードするだけで障害につながることがあります。

本来見られないファイルを閲覧される

ファイルを保存するだけでなく、ダウンロード時のアクセス制御も重要です。

例えば、

https://example.com/files/1001.pdf

というURLで契約書を閲覧できるとします。

URLの数字を、

1001
↓
1002

へ変更するだけで別の顧客の契約書を閲覧できる設計なら、重大な情報漏えいにつながります。

ファイルをダウンロードするときにも、

「このユーザーはこのファイルを閲覧できるか」

を確認する必要があります。

ファイルアップロードのセキュリティ対策で重要な12項目

ファイルアップロード機能では、一つの対策だけに依存しないことが重要です。

複数の対策を組み合わせて安全性を高めます。

1. アップロード可能なファイル種類を限定する

最初に決めたいのが、

「何をアップロードできる必要があるのか」

です。

例えば契約書管理システムなら、

• PDF
• Word
• Excel

だけで十分かもしれません。

商品画像なら、

• JPEG
• PNG
• WebP

などに限定できます。

逆に、

「何でもアップロード可能」

という仕様は避けた方が安全です。

許可リスト方式で考える

ファイル種類は、

「危険な拡張子だけ禁止する」

という方法より、

「必要な種類だけ許可する」

というAllowlist（許可リスト）方式が基本です。

例えばPDFとExcelだけ必要なら、

.pdf
.xlsx

だけを許可します。

将来的に必要なファイルが増えたら、その時点で追加します。

2. 拡張子だけで判定しない

非常に重要なポイントです。

例えば、

malware.exe

というファイルを、

document.pdf

へ名前変更することは簡単にできます。

そのため、

「ファイル名が.pdfで終わっているからPDF」

と判断するだけでは不十分です。

拡張子はチェック項目の一つとして利用できますが、それだけに依存しないようにします。

3. MIMEタイプを確認する

ファイルアップロードではMIMEタイプも確認します。

MIMEタイプとは、

「そのデータがどの種類のファイルなのか」

を表す情報です。

例えば、

PDF
→ application/pdf

JPEG
→ image/jpeg

PNG
→ image/png

などです。

ただし、ブラウザから送られてくるMIMEタイプをそのまま信用するのも適切ではありません。

クライアント側から送信される情報は改変できるためです。

可能であれば、サーバー側で実際のファイル内容を確認して種類を判定します。

つまり、

• 拡張子
• MIMEタイプ
• 実際のファイル内容

を組み合わせて確認することが重要です。

4. ファイルサイズを制限する

ファイルサイズには上限を設定します。

例えば、

プロフィール画像
→ 5MBまで

契約書
→ 20MBまで

CSV
→ 10MBまで

といった形です。

上限値は業務内容によって変わります。

重要なのは、

「とりあえず100MB」

ではなく、実際に必要なファイルサイズを確認することです。

システム全体でも制限する

アプリケーションだけでなく、

• Webサーバー
• API Gateway
• リバースプロキシ
• クラウドストレージ

などにもアップロード上限が存在する場合があります。

例えばアプリ側では100MBまで許可していても、その手前のインフラが10MBまでならアップロードできません。

そのため、ファイルサイズ制限はシステム全体で確認します。

5. ファイル名をシステム側で変更する

アップロードされたファイル名を、そのまま内部保存名として使用することは避けます。

例えば、

ユーザーがアップロード：
2026年度_契約書.pdf

内部保存：
550e8400-e29b-41d4-a716-446655440000.pdf

のように、UUIDなどシステム側で生成した名前へ変更します。

データベースには、

表示用ファイル名：
2026年度_契約書.pdf

内部保存名：
550e8400-e29b-41d4-a716-446655440000.pdf

というように別々に保存できます。

これにより、

• ファイル名重複
• 特殊文字
• パストラバーサル
• 予測可能なURL

などの問題を避けやすくなります。

6. Web公開領域へそのまま保存しない

アップロードされたファイルを、

/public/uploads/

のようなWebから直接アクセスできる領域へそのまま保存すると、設計によってはリスクが高くなります。

業務システムでは、

ユーザー
↓
ダウンロード要求
↓
アプリケーションで権限確認
↓
ストレージから取得
↓
ユーザーへ返却

という形にすると、アクセス制御しやすくなります。

クラウド環境であれば、

• Amazon S3
• Google Cloud Storage
• Azure Blob Storage

などのオブジェクトストレージを非公開設定で利用する方法もあります。

重要なのは、

URLを知っているだけで誰でも閲覧できる状態にしないこと

です。

7. ダウンロード時にも認可チェックを行う

ファイルアップロードのセキュリティというと、登録時のチェックばかり考えがちです。

しかし、業務システムではダウンロード時の権限確認も同じくらい重要です。

例えば顧客管理システムで、

顧客A
→ 営業担当者Aのみ閲覧可能

顧客B
→ 営業担当者Bのみ閲覧可能

という権限があるとします。

ファイルをダウンロードするときにも、

ログインユーザー
↓
対象ファイル
↓
関連する顧客
↓
閲覧権限確認
↓
許可された場合のみダウンロード

という処理が必要です。

URLを推測しにくくするだけでは不十分

UUIDなど予測しにくいURLを使うことは一定の意味があります。

しかし、

「URLを知らなければ見られない」

だけでは、本来のアクセス制御にはなりません。

最終的にはサーバー側で認可判定を行います。

8. ウイルス・マルウェアチェックを検討する

社内でファイルを共有するシステムでは、アップロードされたファイルをウイルススキャンする方法があります。

例えば、

ユーザーがアップロード
↓
一時領域へ保存
↓
ウイルススキャン
↓
問題なし
↓
本保存
↓
利用可能

という流れです。

問題が検出された場合は、本来の保存領域へ移動しません。

すべてのシステムで同じ対策が必要とは限らない

例えば、

「管理者1人だけが商品画像をアップロードする」

システムと、

「不特定多数の外部ユーザーがファイルを投稿できる」

システムではリスクが異なります。

そのため、

• 誰がアップロードするのか
• 誰がダウンロードするのか
• どのようなファイルを扱うのか
• 外部ユーザーが存在するか

によって必要な対策を判断します。

9. HTMLやSVGなどブラウザで実行されるファイルに注意する

ファイルは保存するだけだから安全、とは限りません。

例えばHTMLをアップロードし、それをブラウザ上で直接表示できる仕組みにすると、JavaScriptなどが実行される可能性があります。

SVGも画像形式の一つですが、扱い方によってはスクリプトなどを含められるため注意が必要です。

「画像だから安全」

と拡張子だけで判断しないようにします。

業務上不要であれば、こうしたファイル形式は許可しない方がシンプルです。

10. 画像は再エンコードする方法もある

画像アップロードでは、

ユーザーが画像登録
↓
システム側で読み込み
↓
必要なサイズへ変換
↓
JPEGやWebPとして再生成
↓
保存

という方法があります。

例えばプロフィール画像であれば、

5000×5000ピクセルの巨大画像

をそのまま保存する必要はないかもしれません。

システム側で、

800×800ピクセル

などへ縮小することで、

• ストレージ容量
• 通信量
• 表示速度

の改善にもつながります。

ただし、画像処理ライブラリ自体にも脆弱性が発見される可能性があるため、依存ライブラリの更新も必要です。

11. アップロード回数・保存容量も制御する

1ファイルあたり10MBに制限しても、

10MB × 10万ファイル

を登録されれば大量の容量が必要です。

そのため、システムによっては、

• 1ユーザーあたりの保存容量
• 1日あたりのアップロード数
• 1案件あたりのファイル数
• 組織単位の保存容量

などを制限します。

例えば、

1案件あたり最大20ファイル
1ファイル最大20MB

とする方法です。

外部ユーザーが利用するシステムでは、レート制限も検討します。

12. 操作ログを残す

業務システムでは、

「誰がファイルを登録したか」

だけでなく、

• 誰が
• いつ
• どのファイルを
• アップロードしたか
• ダウンロードしたか
• 削除したか

を記録することも重要です。

例えば、

2026/07/30 10:15
ユーザー：山田太郎
操作：アップロード
ファイル：契約書.pdf
対象：顧客ID 125

といった履歴です。

個人情報や契約書など重要な文書を扱う場合、問題発生時の調査にも役立ちます。

フロントエンドだけのチェックでは不十分

ファイルアップロード画面では、

「PDFしか選択できない」

ように設定することがあります。

ユーザーの操作ミスを減らす意味では有効です。

しかし、セキュリティ対策としてフロントエンドだけに依存してはいけません。

APIを直接呼び出せば、画面の制限を回避できる場合があるためです。

そのため、

フロントエンド

• 選択可能なファイル種類を制限
• サイズを事前確認
• エラーメッセージを表示

バックエンド

• 拡張子確認
• ファイル内容確認
• MIMEタイプ確認
• サイズ確認
• 権限確認
• 保存処理

というように役割を分けます。

セキュリティ上重要な検証は必ずサーバー側でも行う

ことが基本です。

ファイルをデータベースへ保存する？ストレージへ保存する？

ファイルアップロード機能を設計すると、

「ファイル自体をデータベースへ保存するのか」

という問題があります。

一般的なWebシステムでは、

データベース

• ファイルID
• 元ファイル名
• 保存先
• MIMEタイプ
• サイズ
• 登録ユーザー
• 登録日時
• 関連する顧客や案件

などのメタデータを保存。

オブジェクトストレージ

PDFやExcelなど、実際のファイル本体を保存。

という構成があります。

例えば、

顧客テーブル
↓
添付ファイルテーブル
↓
S3などのストレージ

という形です。

この構成にすると、業務データとファイル本体を分けて管理できます。

【具体例】契約書アップロード機能を安全に設計する

顧客管理システムへ契約書を登録するケースを考えてみます。

要求

営業担当者が顧客詳細画面から契約書をアップロードしたい。

利用するファイルは、

• PDF
• Word

です。

最大20MBとします。

悪い設計例

ユーザーがファイル選択
↓
ファイル名をそのまま利用
↓
/public/uploads/へ保存
↓
URLを画面へ表示

この方法では、

• ファイル名
• ファイル種類
• 権限
• 公開範囲

などの問題が残ります。

改善した設計例

営業担当者
↓
ログイン確認
↓
顧客に対する編集権限確認
↓
ファイル選択
↓
サイズ確認
↓
許可されたファイル形式か確認
↓
ファイル内容確認
↓
システム側で保存名を生成
↓
非公開ストレージへ保存
↓
データベースへメタ情報登録

ダウンロード時は、

ユーザー
↓
ログイン確認
↓
ファイル情報取得
↓
対象顧客への閲覧権限確認
↓
一時的なダウンロードURL発行
↓
ダウンロード

という流れにします。

このように、

アップロードとダウンロードの両方で権限を確認する

ことが重要です。

ファイルアップロードと署名付きURL

Amazon S3などのオブジェクトストレージを利用する場合、署名付きURLを使う方法があります。

例えばダウンロード時に、

ユーザーがダウンロードボタンを押す
↓
アプリケーションが閲覧権限を確認
↓
数分間だけ有効なURLを発行
↓
ユーザーがストレージから直接ダウンロード

という構成です。

これにより、ストレージ自体を公開せずにファイルを提供できます。

アップロードでも、

アプリケーション
↓
アップロード用URLを発行
↓
ブラウザから直接ストレージへ送信

という方法があります。

大容量ファイルの場合、アプリケーションサーバーを経由しないため負荷を抑えやすくなります。

ただし、署名付きURLを利用する場合でも、

• 有効期限
• 対象ファイル
• アップロード可能サイズ
• アップロード後の検証

などを考える必要があります。

CSVアップロードでは別の注意点もある

業務システムではCSVによる一括登録機能もよく利用されます。

例えば、

商品マスタ.csv
顧客一覧.csv
在庫データ.csv

などです。

CSVの場合は、通常のファイル保存だけでなく、

「ファイルの中身をシステムへ取り込む」

ため、別の対策も必要です。

行数を制限する

100万行のCSVを一度に処理すると、大きな負荷がかかる可能性があります。

例えば、

最大1万行

など業務上必要な上限を設定します。

カラム数・形式を検証する

想定しているフォーマットが、

顧客名
メールアドレス
電話番号

なら、それ以外の形式をそのまま処理しないようにします。

文字コードも確認する

CSVでは、

• UTF-8
• Shift_JIS

など文字コードの違いによって文字化けする場合があります。

アップロード仕様で対応する文字コードを決めておくことも重要です。

ファイル削除はどう設計する？

アップロードだけでなく削除も考える必要があります。

例えばユーザーが削除ボタンを押した場合、

完全削除

ストレージから即座に削除する。

論理削除

データベース上では削除済みにし、一定期間ファイルを残す。

という方法があります。

業務システムでは、

「誤って契約書を削除した」

ということも考えられます。

そのため、

削除
↓
30日間保持
↓
完全削除

のような運用もあります。

ただし、保存期間については会社の文書管理ルールや扱う情報に応じて決める必要があります。

ファイルアップロード機能を設計するときのチェックリスト

【コピペ用】ファイルアップロード セキュリティチェックリスト

ファイル種類

• [ ] アップロード可能な拡張子を決めている
• [ ] 必要なファイルだけ許可している
• [ ] 拡張子だけで判定していない
• [ ] MIMEタイプを確認している
• [ ] ファイル内容も確認している

サイズ・容量

• [ ] 1ファイルあたりのサイズ上限がある
• [ ] 一度にアップロードできるファイル数に上限がある
• [ ] ユーザー・組織単位の保存容量を検討している
• [ ] 大量アップロードへの対策がある

ファイル名

• [ ] ユーザーのファイル名をそのまま内部保存名にしていない
• [ ] UUIDなどシステム側で保存名を生成している
• [ ] 元のファイル名は表示用情報として管理している

保存先

• [ ] ファイルを無条件にWeb公開していない
• [ ] 非公開ストレージを利用している
• [ ] ストレージのアクセス権限を設定している

権限

• [ ] アップロード時に権限確認している
• [ ] ダウンロード時にも権限確認している
• [ ] 削除時にも権限確認している
• [ ] URLを推測するだけでは閲覧できない

セキュリティ

• [ ] サーバー側でファイルを検証している
• [ ] 必要に応じてマルウェアスキャンを行っている
• [ ] HTML・SVGなどの扱いを検討している
• [ ] 操作ログを保存している

運用

• [ ] ファイル保持期間を決めている
• [ ] 削除ルールを決めている
• [ ] バックアップ方針を決めている
• [ ] 問題ファイルを無効化できる

ファイルアップロード機能でよくある失敗

accept属性だけでファイルを制限する

HTMLのファイル選択画面で、

「PDFだけ選択可能」

にしても、それだけではセキュリティ対策になりません。

APIへ直接ファイルを送信される可能性があるため、サーバー側でも検証します。

拡張子しか確認していない

.pdfという名前でも、本当にPDFとは限りません。

拡張子に加え、ファイル内容なども確認します。

元のファイル名で保存する

同じファイル名がアップロードされると上書きされたり、特殊文字によって問題が発生したりする可能性があります。

内部保存名はシステム側で生成する方法が安全です。

ファイルを公開フォルダへ置く

ログインが必要な業務システムなのに、添付ファイルだけURLを知れば誰でも閲覧できるケースがあります。

業務システムの認証・権限とファイルアクセスも連動させることが重要です。

管理者ならすべてのファイルを見られる設計にする

システム管理権限と業務上の閲覧権限は別物です。

例えばシステム設定を変更できる担当者だからといって、人事書類や機密契約書まで閲覧する必要があるとは限りません。

業務要件に応じて権限を分けます。

ファイルアップロードのセキュリティに関するよくある質問

拡張子をチェックすれば安全ですか？

十分ではありません。

ファイル名は簡単に変更できるため、

• 拡張子
• MIMEタイプ
• 実際のファイル内容

などを組み合わせて確認することが重要です。

PDFだけなら安全ですか？

PDFだから必ず安全とは限りません。

不正な内容を含むファイルや、脆弱性を悪用する目的で作られたファイルが存在する可能性があります。

利用者やシステムの性質に応じて、マルウェアスキャンなども検討します。

ファイルはデータベースへ保存した方が安全ですか？

必ずしもそうとは限りません。

一般的なWebシステムでは、実ファイルをオブジェクトストレージなどへ保存し、データベースにはファイル情報を保存する構成があります。

重要なのは保存場所そのものより、

• 公開範囲
• アクセス制御
• 暗号化
• バックアップ
• 権限管理

などを適切に設計することです。

S3へ保存すれば安全ですか？

S3などのクラウドストレージを利用するだけで自動的に安全になるわけではありません。

公開設定やアクセス権限を誤れば、情報漏えいにつながる可能性があります。

基本的には非公開にし、アプリケーションで認可確認してからアクセスさせる構成を検討します。

ファイル名は変更した方がよいですか？

内部保存名はシステム側で生成する方法が推奨されます。

利用者が付けた元のファイル名は、画面表示用としてデータベースへ保存できます。

ウイルスチェックは必須ですか？

システムの利用者や扱うファイルによって必要性が変わります。

特に、

• 外部ユーザーがアップロードできる
• ファイルを複数人で共有する
• Officeファイルなどを扱う
• 重要な業務システムである

といった場合には検討する価値があります。

画像アップロードでも対策は必要ですか？

必要です。

画像でも、

• ファイルサイズ
• ファイル形式
• 不正ファイル
• ストレージ大量消費
• SVGなどの特殊形式

を考慮します。

必要に応じてサーバー側で画像を再生成する方法もあります。

hiro-dev-labではファイル管理を含む業務システム設計から相談できます

業務システムでは、

「ファイルを添付できるようにしたい」

という要求から始まっても、実際に設計すると、

• 誰がアップロードできるか
• 何をアップロードできるか
• 最大サイズはいくつか
• 誰が閲覧できるか
• どこへ保存するか
• いつ削除するか
• 操作履歴を残すか
• 外部ユーザーにも利用させるか

など、多くの要件を決める必要があります。

hiro-dev-labでは、ファイルアップロード機能単体ではなく、実際の業務を確認したうえで必要なシステム構成を整理できます。

例えば、

• 現在のファイル管理方法のヒアリング
• 業務フロー整理
• 要求整理
• 要件定義
• ユーザー・権限設計
• ファイル管理機能設計
• クラウドストレージ構成
• アップロード・ダウンロード機能
• 操作ログ設計
• Webシステム設計・開発

などです。

例えば現在、

「契約書をメール添付して担当者同士で共有している」
「顧客ごとのフォルダを共有サーバーで管理している」
「ExcelやPDFがどこにあるのか分からなくなる」

といった業務であれば、単なるファイルアップロード機能ではなく、顧客管理や案件管理と組み合わせた文書管理機能として整理する方法もあります。

まとめ

ファイルアップロード機能は、業務システムではよく使われる一方、外部からデータを受け取るためセキュリティ上慎重な設計が必要な機能です。

特に重要なのは、

• アップロード可能なファイル形式を限定する
• 拡張子だけで判断しない
• MIMEタイプやファイル内容を確認する
• ファイルサイズを制限する
• 内部ファイル名をシステム側で生成する
• Webから直接公開しない
• アップロード・ダウンロード時に権限確認する
• 必要に応じてマルウェアスキャンする
• 操作ログを残す

といった対策です。

また、

「ファイルアップロード時に危険なファイルを防ぐ」

だけでなく、

「保存したファイルを誰が閲覧・削除できるのか」まで含めて設計する

ことが重要です。

顧客管理、案件管理、契約管理、申請・承認などの業務システムでは、ファイルは業務データと密接に関係します。

そのため、ファイルアップロード機能だけを切り離して考えるのではなく、

「誰が、どの業務で、どのファイルを扱うのか」

を整理したうえで、認証・権限・保存先・履歴まで含めて設計することが、安全で使いやすい業務システムにつながります。