セキュリティ

上場企業3,700社のSPF/DMARC設定を全調査 — 「p=none」が半数、日本のメール認証の現在地 @yoppy0123 氏のポストが、上場企業のメール認証設定を網羅的に調査した Zenn 記事を紹介しています。 上場企業（約3,700社）を対象にSPF / DMARCの設定状況を調査した記事です。実際のところどうなんだろう？と気になっていたので、とても参考になりました！ 元記事は ext0mmy 氏による「上場企業約3,700社のSPF/DMARC設定状況調査」です。2026年3月1日時点で、JPX（日本取引所グループ）に上場する3,745社を対象に、DNS レコードから SPF と DMARC の設定状況を調査しています。 Google が Gmail の送信者ガイドラインで DMARC 対応を義務化してから2年。日本の上場企業はどこまで対応が進んだのか、調査結果を技術的な背景とともに解説します。 メール認証の基礎 — SPF・DKIM・DMARC の仕組み 調査結果を読み解くために、まずメール認証の3つの技術を整理します。 SPF（Sender Policy Framework） SPF は、メールの送信元 IP アドレスを検証する技術です。ドメインの DNS レコードに「このドメインからメールを送信してよい IP アドレスの一覧」を登録しておき、受信側がそれを照合します。 example.co.jp IN TXT "v=spf1 include:_spf.google.com ~all" 末尾の修飾子が認証失敗時のポリシーを決定します。 修飾子 意味 厳しさ +all 全て許可 設定する意味がない ~all（softfail） 認証失敗を記録するが配信は許可 緩い -all（fail） 認証失敗のメールを拒否 厳しい DKIM（DomainKeys Identified Mail） DKIM は、メールに電子署名を付与し、送信中の改ざんを検知する技術です。送信サーバがメールヘッダとボディに署名を付け、受信サーバが DNS に公開された公開鍵で検証します。SPF が「どこから送ったか」を検証するのに対し、DKIM は「改ざんされていないか」を検証します。 DMARC（Domain-based Message Authentication, Reporting and Conformance） DMARC は、SPF と DKIM の認証結果を束ねて、認証失敗時の処理方針を定めるフレームワークです。 ...

FIDO2 認証（パスキー）の仕組み — パスワードを「構造的に不要にする」技術 サイボウズのバグバウンティで複数年度 1 位の実績を持つセキュリティ研究者 @yousukezan さんのポストで紹介されていた、FIDO2 認証（パスキー）の概要記事を深掘りします。元記事は Nagano さんの Zenn 記事です。 2026 年現在、日本証券業協会がパスキー（FIDO2）の導入を必須化するガイドラインを施行し、楽天証券・SMBC 日興証券などが相次いで導入を進めています。パスキーはもはや「新しい技術」ではなく「必須のインフラ」になりつつあります。 パスワード認証の根本的な問題 パスワード認証には、仕組みそのものに起因する構造的な脆弱性があります。 graph LR USER["ユーザー"] -->|パスワードを送信| SERVER["サーバー"] ATTACKER["攻撃者"] -.->|盗聴・フィッシング| USER style USER fill:#3498db,color:#fff style SERVER fill:#2ecc71,color:#fff style ATTACKER fill:#e74c3c,color:#fff 脅威 内容 フィッシング 偽サイトにパスワードを入力させる リスト型攻撃 漏洩したパスワードを他サービスで試行 中間者攻撃 通信を傍受してパスワードを盗む サーバー侵害 サーバーに保存されたパスワードハッシュの漏洩 これらの問題は「秘密情報（パスワード）をネットワーク経由で送信する」という設計そのものに起因します。ワンタイムパスワード（OTP）でも、この根本構造は変わりません。実際、日本証券業協会は 2025 年 10 月のガイドライン改正で、OTP の利用を非推奨としています。 FIDO2 の設計思想 — 「秘密を送らない」 FIDO2 は発想を根本から変えました。秘密情報をネットワーク上に一切流さない認証方式です。 graph LR subgraph デバイス側 USER2["ユーザー"] -->|生体認証/PIN| AUTH["認証器<br/>（TPM等）"] AUTH -->|秘密鍵で署名| SIGNED["署名データ"] end subgraph サーバー側 SIGNED -->|署名のみ送信| VERIFY["公開鍵で検証"] end style USER2 fill:#3498db,color:#fff style AUTH fill:#f39c12,color:#fff style SIGNED fill:#9b59b6,color:#fff style VERIFY fill:#2ecc71,color:#fff パスワード認証では「秘密そのもの」を送信しますが、FIDO2 では「秘密鍵で作った署名」だけを送信します。秘密鍵はデバイス内の安全な領域（TPM、Secure Enclave 等）に保管され、外部に出ることはありません。 ...

django-oauth-toolkit 2.0 の client_secret ハッシュ化で外部連携が壊れた話 TL;DR django-oauth-toolkit を 1.x から 2.0 にアップグレードすると、Application.client_secret が 平文からハッシュ値に自動変換 される。この変更に気づかず、DB 上のハッシュ値を「シークレット」として外部サービスにコピーすると、二重ハッシュ で認証が通らなくなる。さらに、Application を動的に生成するコードがある場合、バージョンアップ後に平文を返すべき箇所でハッシュ値を返してしまう問題も起きる。 背景 2つの Django サービス間で OAuth2 Client Credentials Grant による認証を行っていた。 サービス 役割 django-oauth-toolkit Service A (リソースサーバー) ファイル配信 API を提供 2.4.0 Service B (クライアント) API からファイルを取得 1.7.1 Service B は Service A の OAuth2 トークンエンドポイントに HTTP Basic Auth で client_id:client_secret を送信し、アクセストークンを取得してからファイルをダウンロードする。 Service B Service A | | |-- POST /o/token/ --------------->| | Authorization: Basic base64( | | client_id:client_secret) | | |-- client_secret をハッシュ化 | |-- DB のハッシュ値と比較 |<-- access_token -----------------| | | |-- GET /api/files/ -------------->| | Authorization: Bearer token | |<-- file data --------------------| このフローは数年間安定稼働していた。 ...

CTA ビデオ埋め込み viemoなどiframe配信できるサーバーにホスティングしているビデオが対象 vimeoの muted=1&autoplay=1 でも自動再生はできない (セキュリティ上の問題。自動再生は、ユーザーのトリガーがないとしてくれないケースがある) ショートムービーをアニメーションGIFに変換: 1 ffmpeg -i input.mp4 -r 10 output.gif

Contentful CDA / CMA Contentful における Content Delivery API キーと CMA トークンの用途の違いについて説明します。 Content Delivery API キー (CDA キー) 用途: コンテンツ配信 API (CDA) へのアクセスを認証するために使用されます。 役割: 公開されたコンテンツを取得するために使用されます。ウェブサイトやモバイルアプリなどのフロントエンドアプリケーションから Contentful のコンテンツを読み込む際に、このキーが使用されます。 特徴: 読み取り専用のアクセス権を持ちます。コンテンツの作成、更新、削除などの変更操作はできません。 セキュリティ: 比較的安全性が低いとされています。キーが漏洩した場合でも、コンテンツの変更はできませんが、コンテンツを不正に取得される可能性があります。 Content Management API トークン (CMA トークン) 用途: コンテンツ管理 API (CMA) へのアクセスを認証するために使用されます。 役割: Contentful のコンテンツを管理 (作成、更新、削除など) するために使用されます。Contentful のバックエンドシステムや管理画面、または外部のツールから Contentful のコンテンツを操作する際に、このトークンが使用されます。 特徴: 読み取り/書き込みのアクセス権を持ちます。コンテンツの変更操作が可能です。 セキュリティ: 非常に高いセキュリティが必要です。トークンが漏洩した場合、コンテンツを不正に操作される可能性があります。 まとめ 機能 Content Delivery API キー Content Management API トークン 用途 コンテンツ配信 API へのアクセス コンテンツ管理 API へのアクセス 役割 公開されたコンテンツの取得 コンテンツの管理 (作成、更新、削除など) アクセス権 読み取り専用 読み取り/書き込み セキュリティ 比較的低い 非常に高い 注意点 ...

Wordpress脆弱性 Advanced Custom Fields (ACF) https://rocket-boys.co.jp/7886/

Hassura PostgreSQL サーバーから自動的に GraphQL サーバーを建てられる, PostgreSQL サーバーがあればすぐに使える GraphQL サーバーを実装する手間が省ける 他の自前で用意したGraphQLサーバーとHasuraを統合してリクエストをHasura一つにお任せすることも可能 ページングや集計クエリなども自動で生成される 実際に発行される SQL がすぐにわかる 認証認可の仕組みがある ドキュメント https://hasura.io/learn/ja/graphql/hasura/introduction/ 記事 Hasuraがめちゃくちゃ便利だよという話 Hasuraを使って環境構築してガンガン工数削減

AppExchange ISV / OEM パートナー 組織 パートナービジネス組織（Partner Business Org で PBO とも呼ばれる） パッケージ開発組織 スクラッチ組織（Scratch Org） Trialforce ソース組織（Trialforce Source Org で TSO とも呼ばれる） 顧客組織 開発 LMA 環境ハブ セキュリティレビュー Salesforce のアプリケーション審査 手順: 準備 申請 注文書と手順書 公開 年次更新 Lightning Experience Lightning コンポーネントフレームワークとは? Lightning コンポーネント: コードを一行も記述することなくビジネスアプリを開発できます。 Aura コンポーネント コンポーネント: Visualforce Aura(いわゆるオーラ) (Aura コンポーネントの中から LWC を呼び出すことはできるが、LWC の中から Aura コンポーネントを呼び出すことはできない。) Lightning Web Conponent(LWC) 外部のデータソースを呼ぶには Apex Aura コンポーネントから Salesforce 以外の外部データを呼び出すには、以下の手順を参考にしてください： Apex コントローラーを使用する: Apex クラスを作成し、外部 API を呼び出すメソッドを定義します。例えば、HttpRequestとHttpResponseクラスを使用して外部 API にリクエストを送信し、レスポンスを処理します。 public class ExternalDataController { @AuraEnabled public static String getExternalData() { Http http = new Http(); HttpRequest request = new HttpRequest(); request.setEndpoint('https://api.example.com/data'); request.setMethod('GET'); HttpResponse response = http.send(request); return response.getBody(); } } Aura コンポーネントで Apex メソッドを呼び出す: ...

さくらのレンタルサーバー 無料 SSL（Let’s Encrypt）を設定したい SSL 証明書の設定をはじめからやり直したい（さくらの有償 SSL・独自 SSL） CSR を作成したい

サイトセキュリティチェック Mozilla: https://observatory.mozilla.org/ トレンドマイクロ: https://global.sitesafety.trendmicro.com/?cc=jp Google: https://www.virustotal.com/gui/home/upload OWASP Zap Docker 版 OWASP ZAP を M1 Mac で動かす。 問題: : Cookie No HttpOnly Flag [10010] : Re-examine Cache-control Directives [10015] : Cross-Domain JavaScript Source File Inclusion [10017] : Missing Anti-clickjacking Header [10020] : X-Content-Type-Options Header Missing [10021] : [Information Disclosure - Suspicious Comments]https://www.zaproxy.org/docs/alerts/10027/ : [Cookie Poisoning]https://www.zaproxy.org/docs/alerts/10029/ : User Controllable HTML Element Attribute (Potential XSS) [10031] : Strict-Transport-Security Header Not Set [10035] : Content Security Policy (CSP) Header Not Set [10038] : Secure Pages Include Mixed Content [10040] : Storable and Cacheable Content [10049] : Cookie without SameSite Attribute [10054] : Permissions Policy Header Not Set [10063] : Timestamp Disclosure - Unix [10096] : Modern Web Application [10109] (対応しなくてもよい) : Dangerous JS Functions [10110] : Session Management Response Identified [10112] : Absence of Anti-CSRF Tokens [10202] : Sub Resource Integrity Attribute Missing [90003] : Charset Mismatch [90011] VIRUSTOTAL https://www.virustotal.com/gui/home/upload SUURI https://sitecheck.sucuri.net/