403 エラーの記事一覧

冒頭まとめ OpenAI API の 403 は、公式のエラー一覧では1項目しか定義されていません。国・地域・領域が対応外である、というものです。 このエラーには、他と違う特徴があります。応答の type が invalid_request_error ではなく request_forbidden になります。code は unsupported_country_region_territory です。この2語が見えた時点で、系統が確定します。 そして最も重要な点です。判定されているのは利用者の所在地ではなく、要求の送信元 IP アドレスがどこと判定されたかです。対応国にいても、経路の途中で別の地域と判定されれば 403 になります。実際、提供元の窓口も利用者に対し、IP アドレスを教えてほしい、正しくない地域に判定されていないか確認する、と応じています。 もう1つ、プログラムから呼んだ場合の 403 として、資源へのアクセス権が無い場合があります。公式のソフトウェア開発キットでは、要求した資源へのアクセス権が無い状態として定義され、正しいキー・組織 ID・資源 ID を使っているか確認するよう案内されています。 逆に、403 だと思われがちだが違うものがあります。残高や利用額の上限は 429、モデルへのアクセス権は 404、キーの失効や組織の不一致は 401 です。いずれも 403 では返りません。 エラーの概要 地域の非対応は、次の形で返ります。 { "error": { "code": "unsupported_country_region_territory", "message": "Country, region, or territory not supported", "param": null, "type": "request_forbidden" } } 他のエラーと並べると違いが際立ちます。400 や 401 の type は invalid_request_error ですが、こちらは request_forbidden です。type を見るだけで、内容の問題でも認証の問題でもないと分かります。 もう1つ確認すべきことがあります。応答が JSON かどうかです。上の形が返っていれば、API の層が判断した結果です。JSON ではなく HTML の遮断画面が返っている場合、判断したのは API の層ではなく、その手前にある仕組みです。調べる先が変わるため、本文の形式を最初に確認してください。 まず最初に：type と送信元 IP を確認する 第一に、type を読みます。request_forbidden であれば地域の系統です。 ...

エラーの概要 GitLab の 403 エラーは、認証済みのユーザーがプロジェクトやリソースへのアクセス権限を持たないときに返されるアクセス拒否エラーです。認証自体は成功していますが、実行しようとしたアクション（プッシュ、マージリクエストの作成、設定変更など）の権限がないことを示します。GitLab での権限管理はロールベースアクセス制御（RBAC）に基づいており、プロジェクトメンバーシップ、グループ設定、ブランチ保護ルールなどの複数の層で管理されるため、原因の特定には段階的な確認が必要です。 実際のエラーメッセージ例 Git コマンドライン実行時： $ git push origin feature-branch remote: GitLab: You are not allowed to push code to this project. fatal: unable to access 'https://gitlab.example.com/group/project.git/': The requested URL returned error: 403 GitLab Web UI のレスポンス： { "message": "403 Forbidden", "error": "You do not have permission to perform this action" } パイプラインや API 呼び出し時： $ curl -H "PRIVATE-TOKEN: <your-token>" https://gitlab.example.com/api/v4/projects/123/issues {"message":"403 Forbidden"} よくある原因と解決手順 原因1：プロジェクトメンバーのロール権限が不足している GitLab では、プロジェクトへのアクセスレベルが細分化されています。Guest（ゲスト）や Reporter（レポーター）ロールでは、コードのプッシュやマージリクエストの承認などの重要な操作ができません。ユーザーが必要な操作を実行しようとしても、割り当てられたロールに権限がなければ 403 エラーが発生します。 修正方法： GitLab の Web UI から、対象プロジェクトの Settings → Members に移動し、ユーザーのロールを Developer 以上に変更します。変更後、ユーザーはコードをプッシュできるようになります。 ...

エラーの概要 Terraform が AWS などのクラウドプロバイダーにリソースの作成・更新・削除を要求したとき、IAM ポリシーまたは SCP（Service Control Policy）により操作が拒否される状態です。このエラーは実行ロールに必要な権限がないか、組織レベルの制限によって操作が許可されていないことを示しています。 実際のエラーメッセージ例 { "Error": { "Code": "AccessDenied", "Message": "User: arn:aws:iam::123456789012:user/terraform-user is not authorized to perform: ec2:RunInstances on resource: arn:aws:ec2:us-east-1:123456789012:instance/* with an implicit deny in user-based policy" } } Error: error creating EC2 Instance: UnauthorizedOperation.Unavailable: You are not authorized to perform this operation. status code: 403, request id: <request-id> on main.tf line 10, in resource "aws_instance" "example": 10: resource "aws_instance" "example" { よくある原因と解決手順 原因1：実行ロールに IAM ポリシーの権限が不足している Terraform を実行するユーザーまたはロールに、リソース作成に必要な IAM 権限がアタッチされていません。例えば EC2 インスタンスを起動する場合、ec2:RunInstances アクションの許可が必要です。IAM ポリシーシミュレーター（ポリシーが実際に機能するかを事前検証するツール）で実際に権限が付与されているかを確認し、不足している権限をポリシーに追加します。 ...

エラーの概要 Azure リソースへのアクセスが拒否されたことを示す HTTP 403 エラーです。このエラーは、ユーザーやアプリケーションが認証には成功（401 ではなく）したものの、対象リソースに対する操作権限がないことを意味します。Azure では RBAC（ロールベースアクセス制御）、Azure Policy、ネットワーク設定などの複数のレイヤーで権限チェックが行われるため、403 が頻繁に発生します。 実際のエラーメッセージ例 Azure Portal や Azure CLI を通じて 403 エラーが出力される場合、以下のような形式で表示されます。 { "error": { "code": "AuthorizationFailed", "message": "The client 'xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx' with object id 'xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx' does not have authorization to perform action 'Microsoft.Compute/virtualMachines/write' over scope '/subscriptions/<subscription-id>/resourceGroups/<resource-group>/providers/Microsoft.Compute/virtualMachines/<vm-name>'." } } $ az vm create --resource-group <resource-group> --name <vm-name> ... (AuthorizationFailed) The client 'user@example.com' with object id '...' does not have authorization to perform action 'Microsoft.Compute/virtualMachines/write' よくある原因と解決手順 原因 1：RBAC で必要なロールが割り当てられていない Azure RBAC により、ユーザーやサービスプリンシパルに対して明示的にロールを割り当てない限り、リソースへの操作は拒否されます。例えば、仮想マシンの作成には「仮想マシン共同作成者」や「共同作成者」ロールが必要です。サブスクリプションやリソースグループレベルでロールが割り当てられていなければ、その配下のすべてのリソース操作が 403 で拒否されます。 ...

エラーの概要 Docker Compose で 403 エラーが発生する場合、これはレジストリ（Docker Hub、プライベートレジストリなど）またはホストマシンのリソースに対して、実行ユーザーが十分なアクセス権限を持っていないことを示しています。プライベートイメージの pull、ボリュームマウント時のファイルアクセス、Docker ソケットへのアクセスなど、複数の場面で発生する可能性があります。 実際のエラーメッセージ例 Docker Hub などのレジストリからのプライベートイメージ pull 時： { "message": "Error response from daemon: pull access denied for myregistry/myimage, repository does not exist or may require 'docker login'", "error": "403 Forbidden" } ボリュームマウントのパーミッション不足時： ERROR: for <service-name> Cannot start service <service-name>: error while creating mount source path '/data/app': permission denied Docker ソケットへのアクセス権限不足時： ERROR: Got permission denied while trying to connect to the Docker daemon socket at unix:///var/run/docker.sock よくある原因と解決手順 原因1：プライベートイメージレジストリへの認証不足 Docker Compose でプライベートイメージを利用する場合、レジストリに対する認証情報が必要です。認証なしにプライベートイメージを pull しようとすると 403 エラーが発生します。 ...

冒頭まとめ GCP の 403 Forbidden は、身元は届いているが、その操作が許されていない状態を示します。認証が通っていない 401 とは段階が違います（GCP の 401 の記事）。 このエラーの扱いやすさは、応答に含まれる情報の多さにあります。公式文書によれば、コマンド行の道具や窓口が返す文言には、必要な権限の名前、操作しようとした対象、認証に使われた身元、エラーごとの識別子、そして原因を調べるための専用の URL が含まれます。つまり、どの権限が足りないかは推測する必要がありません。応答に書かれています。 原因についても、公式文書が4つに整理しています。必要な権限を持っていない場合、拒否の方針が権限の使用を妨げている場合、主体に対する境界の方針が対象を含んでいない場合、そして対象が存在しない場合です。 4つ目が重要です。対象が存在しない場合も、このエラーになります。実際、文言も「対象に対して権限が拒否されました（あるいは対象が存在しない可能性があります）」という形になっており、両方の可能性を含んだ書き方です。したがって、403 を受け取ったからといって、権限の問題とは限りません。名前の綴りを間違えているだけ、ということがあります。 区分の定義にも、このエラーが要求の妥当性や対象の存在を意味しない、と明記されています。 エラーの概要 窓口からの応答は、次の形になります。 { "error": { "code": 403, "message": "Permission 'storage.buckets.list' denied on resource (or it may not exist). Remediate access with this Troubleshooter URL or share it with your administrator - https://console.cloud.google.com/iam-admin/troubleshooter;errorId=<識別子> .", "details": [ { "@type": "type.googleapis.com/google.rpc.ErrorInfo", "reason": "forbidden", "domain": "global", "metadata": { "error_info_id": "<識別子>", "permission": "storage.buckets.list" } } ] } } 読むべきは metadata の中の permission です。ここに、不足している権限の名前がそのまま入ります。上の例なら、ファイル置き場の一覧を取得する権限です。 ...

エラーの概要 Kubernetes の 403 エラーは「Forbidden」を意味し、リクエストの認証は成功しているものの、そのリソースに対する操作権限（RBAC: Role-Based Access Control）がないことを示します。Pod の実行、リソースの取得・更新・削除など、特定の操作がセキュリティポリシーにより拒否された状態です。API サーバーやマニフェスト適用時、kubectl コマンド実行時に頻繁に発生します。 実際のエラーメッセージ例 Error from server (Forbidden): pods "my-pod" is forbidden: User "system:serviceaccount:default:app" cannot get resource "pods" in API group "" in the namespace "default" { "kind": "Status", "apiVersion": "v1", "metadata": {}, "status": "Failure", "message": "deployments.apps \"nginx\" is forbidden: User \"system:serviceaccount:kube-system:default\" cannot create resource \"deployments\" in API group \"apps\" in the namespace \"kube-system\"", "reason": "Forbidden", "details": { "name": "nginx", "group": "apps", "kind": "deployments" }, "code": 403 } よくある原因と解決手順 原因1: ServiceAccount に適切な Role が割り当てられていない ServiceAccount は Kubernetes 内のアカウントであり、Pod がリソースにアクセスする際に使用されます。このアカウントに必要な権限を持つ Role が紐付けられていない場合、403 エラーが発生します。 ...

冒頭まとめ Nginx の 403 Forbidden は、サーバーがリクエストを理解したうえで、アクセスを拒否したときに返されます。原因はほぼ次の6つのいずれかです。ファイル権限の不足、パスの途中の親ディレクトリに実行権限がない、index ファイルがなく autoindex も無効、設定の deny ルール、SELinux/AppArmor、そして upstream(PHP-FPM など)自身が 403 を返すケースです。調査は、設定をいじる前に、まず /var/log/nginx/error.log を読むことから始めます。ログの文言が、どの原因なのかの手がかりになります。 エラーの概要 403 Forbidden は、Nginx がリクエスト自体は正しく受け取り、対象のリソースの場所も分かっているが、アクセスを拒否した状態です。認証情報が足りない 401 Unauthorized とは異なり、再認証しても解決しません。リソースが存在しない 404 Not Found とも異なります。 この違いはエラーログで明確に区別できます。404 はログに No such file or directory と記録され、403 は Permission denied や is forbidden と記録されます。アクセスログは「403 が起きた」ことだけを示し、なぜ起きたかはエラーログが示します。したがって、403 の調査は設定ファイルをいじる前に、まずエラーログを読むことから始めます。 まず最初に：エラーログを読む 原因を切り分ける前に、エラーログの該当行を確認します。 # 直近のエラーを表示 sudo tail -50 /var/log/nginx/error.log # 権限・拒否に関する行だけを抽出 sudo grep -iE "permission denied|forbidden|denied" /var/log/nginx/error.log ログの文言と原因の対応は次のとおりです。 # ファイルまたは親ディレクトリの権限不足 open() "/var/www/html/index.html" failed (13: Permission denied) # index ファイルがなく autoindex も無効 directory index of "/var/www/html/" is forbidden # upstream への接続が拒否された（SELinux でソケット接続が遮られた例） connect() to 127.0.0.1:8080 failed (13: Permission denied) while connecting to upstream この文言で、おおよその原因の見当がつきます。以下、6つの原因を、切り分けるべき順に説明します。 ...

エラーの概要 AWS の 403 エラーは、HTTP ステータスコード 403 Forbidden として返されます。これは認証には成功したものの、実行しようとしている操作に対する IAM (Identity and Access Management) 権限が不足していることを意味します。AWS リソースへのアクセス、API 呼び出し、AWS マネジメントコンソール上での操作など、様々な場面で発生する一般的なエラーです。 実際のエラーメッセージ例 AWS CLI でよく見かける 403 エラーレスポンスを示します。 { "Error": { "Code": "AccessDenied", "Message": "User: arn:aws:iam::123456789012:user/john-dev is not authorized to perform: s3:GetObject on resource: arn:aws:s3:::my-bucket/config.json" } } また、AWS マネジメントコンソール上では、より簡潔なエラーが表示されることもあります。 User: arn:aws:iam::123456789012:user/jane-admin is not authorized to perform: ec2:DescribeInstances on resource: * よくある原因と解決手順 原因 1：IAM ポリシーに必要な Action が含まれていない IAM ポリシーに、実行したい操作（Action）が明示的に許可されていない場合、403 エラーが発生します。例えば S3 バケットから読み取りはできるが、アップロード（PutObject）が許可されていない状況が典型的です。 Before（エラーが起きる IAM ポリシー）： { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "s3:GetObject" ], "Resource": "arn:aws:s3:::my-bucket/*" } ] } このポリシーでは GetObject（読み取り）のみが許可されているため、PutObject でアップロードしようとするとアクセス拒否されます。 ...

エラーの概要 Docker の 403 エラーは、認証（ログイン）には成功したものの、対象のリソース（イメージ、レジストリ、ボリューム等）へのアクセス権限がないことを示します。これはプライベートリポジトリへのアクセス、組織内のアクセス制限、または不十分な認証トークンの権限が原因で発生することがほとんどです。Docker CLI、Docker Desktop、または docker push/pull 時に頻繁に遭遇するエラーです。 実際のエラーメッセージ例 Error response from daemon: Head "https://registry-1.docker.io/v2/myuser/myimage/manifests/latest": unauthorized: authentication required 403 Forbidden { "errors": [ { "code": "DENIED", "message": "permission denied", "detail": "requested access to the resource is denied" } ] } docker push myrepo/myimage:tag denied: requested access to the resource is denied よくある原因と解決手順 原因1：Docker Hub のログイン認証が無効または権限不足 なぜ発生するか：Docker CLI がログインしていない状態、または無効なトークンでリポジトリにアクセスしようとすると、403 エラーが返されます。特にプライベートリポジトリの場合、認証なしでのアクセスが拒否されます。 Before（エラーが起きるコマンド） # ログインせずにプライベートリポジトリをプルしようとする docker pull myusername/private-image:latest # または古い認証情報で実行 docker push myrepo/myimage:tag After（修正後のコマンド） ...