RFC 9116에 따라 출력되며 /.well-known/security.txt에 바로 배포할 수 있습니다.
다른 경로에서의 스푸핑을 방지하기 위해 security.txt의 Canonical URL을 선언하세요
RFC 9116 표준을 준수하는 security.txt 파일을 온라인으로 생성하여 보안 연구원에게 공식적인 취약점 신고 창구를 제공하세요. 실시간 미리보기, 한 번의 클릭으로 복사, /.well-known/security.txt에 바로 배포하면 즉시 적용됩니다.
security.txt는 IETF가 RFC 9116에서 정의한 웹 보안 표준으로, 웹사이트가 보안 연락처 정보를 공개하는 표준화된 방법을 제공하기 위한 것입니다. 보안 연구원(화이트햇 해커)이 귀하의 웹사이트에서 보안 취약점을 발견했을 때 누구에게 연락해야 하는지, 보고서를 어떻게 암호화하여 보내는지, 어떤 공개 정책을 따라야 하는지 알아야 합니다. security.txt가 없으면 연구원이 올바른 담당자를 찾지 못해 취약점이 공개적으로 공개되거나 악의적으로 악용될 수 있습니다. Google, GitHub, Facebook/Meta, 영국 정부, 미국 CISA, 프랑스/이탈리아/네덜란드/호주 정부가 이미 이 표준을 채택했습니다.
RFC 9116 표준에 따라 security.txt는 /.well-known/security.txt 경로에 위치해야 합니다(즉, 웹사이트 루트 디렉터리의 .well-known 폴더 안). 또한 폴백 호환성을 위해 웹사이트 루트 디렉터리에 /security.txt를 하나 더 배치할 수도 있습니다. HTTPS를 통해 접근해야 하며 Content-Type은 text/plain이어야 합니다. 다른 경로에 두면 자동화된 보안 스캐닝 도구가 인식할 수 없습니다.
세 가지 형식을 지원합니다: 메일 주소는 mailto: 접두사를 사용해야 하고(예: mailto:security@example.com), 웹페이지 URL은 https:// 접두사를 사용해야 하며(예: https://example.com/security-report), 전화번호는 tel: 접두사를 사용해야 합니다(예: tel:+1-201-555-0123). 여러 연락처를 한 줄에 하나씩 입력할 수 있으며, 보안 연구원이 가장 편리한 채널을 선택하여 연락할 수 있습니다. 최소한 하나의 메일과 하나의 웹 양식 링크를 제공하는 것을 권장합니다.
Expires는 필수 필드입니다(Contact도 필수이며, 나머지는 선택 사항). Expires는 security.txt 내용의 만료 시간을 나타내며, ISO 8601 형식의 UTC 시간을 사용해야 합니다(예: 2027-12-31T23:59:59Z, Z는 UTC 시간대를 의미). 생성 후 6~12개월 후로 만료되도록 설정하여 정기적으로 보안 연락처 정보를 업데이트하도록 상기시키는 것을 권장합니다. 만료되면 자동화 도구는 해당 파일 정보가 무효화되었을 수 있다고 간주합니다.
Encryption 필드는 PGP 공개키 위치를 가리키는 데 사용되며, 보안 연구원이 이 공개키로 취약점 보고서를 암호화한 후 전송하여 메일 전송 과정에서 취약점 세부 사항이 도청되어 유출되는 것을 방지할 수 있습니다. 이는 필수 필드는 아니지만 강력히 구성할 것을 권장합니다—취약점 정보는 매우 민감하기 때문에 평문 메일은 ISP, 메일 서버 관리자 또는 공격자에게 도청될 수 있기 때문입니다. PGP 공개키를 /.well-known/pgp-key.txt에 배치하고 이 URL을 Encryption 필드에 입력하면 됩니다.
Acknowledgments 필드는 공개 감사 페이지(보안 명예의 전당/Hall of Fame라고도 함)를 가리키며, 귀하에게 보안 취약점을 신고한 연구원의 이름이나 ID를 나열합니다. 이는 보안 연구원의 노력에 대한 공개적인 인정이며, 더 많은 화이트햇 연구원이 귀하의 취약점을 찾도록 유도하는 효과적인 방법이기도 합니다. 많은 보안 연구원이 공개 감사 메커니즘이 있는 웹사이트를 우선적으로 테스트하는데, 이는 그들의 기여가 인정받을 것임을 의미하기 때문입니다.
Policy 필드는 귀하의 취약점 공개 정책(Vulnerability Disclosure Policy, VDP) 페이지로 링크해야 합니다. 이 페이지에는 다음 내용이 명확히 설명되어야 합니다: 어떤 테스트 행위가 허용되는지(예: DDoS 금지, 사용자 데이터 접근 금지 등 금지 사항), 취약점 신고 응답 시간 약속, 버그 바운티 제공 여부, 합법적인 보안 연구에 대한 법적 약속(예: 선의의 연구원을 기소하지 않겠다는 내용) 등. 명확한 Policy는 보안 연구원에게 법적 안정감을 주어 안심하고 문제를 보고할 수 있게 합니다.
Canonical 필드는 security.txt 파일 자체의 정규 URL을 선언하는 데 사용됩니다. 하나의 웹사이트에서 여러 도메인이나 경로로 security.txt에 접근할 수 있을 때(예: example.com과 www.example.com), Canonical 필드는 연구원에게 어떤 URL이 공식적이고 신뢰할 수 있는 버전인지 알려줍니다. 이는 공격자가 특정 경로에 위조된 security.txt를 배치하여 연구원이 공격자에게 취약점 보고서를 보내도록 유도하는 것을 방지할 수 있습니다. 공식 도메인 URL(예: https://example.com/.well-known/security.txt)을 입력하는 것을 권장합니다.
Preferred-Languages는 보안 연구원에게 귀하의 보안 팀이 어떤 언어의 보고서를 처리할 수 있는지 알려주며, 쉼표로 구분된 언어 코드로 표시합니다(예: en, ko, ja). 본 생성기는 현재 사용 중인 페이지 언어에 따라 이 필드를 자동으로 설정합니다. 이는 보안 연구가 전 세계적으로 이루어지며 연구원이 어느 국가에 있을 수 있기 때문에 중요합니다. 지원하는 언어를 미리 명시하면 언어 소통 장애로 인한 의사소통 실패를 피할 수 있습니다.
네, Hiring은 RFC 9116 표준이 정의한 선택적 필드 중 하나입니다. 이 필드는 귀하의 보안 팀 채용 페이지로 연결됩니다. 보안 연구원은 그 자체로 우수한 보안 인재 후보입니다—그들이 귀하 웹사이트의 취약점을 발견할 수 있다는 것은 강력한 보안 역량을 가지고 있음을 의미하며, security.txt에 채용 링크를 넣는 것은 매우 정확한 보안 인재 채용 방식입니다. Google을 포함한 많은 유명 기업이 security.txt에 채용 링크를 넣고 있습니다.
이는 웹사이트 운영자의 가장 흔한 우려 사항입니다. 스팸 메일을 줄이는 몇 가지 방법이 있습니다: 첫째, 메일 주소를 직접 넣지 말고 보안 보고 웹 양식 URL(https:// 접두사)을 넣어 캡차로 봇을 필터링할 수 있습니다. 둘째, 전용 보안 메일 별칭(예: security@)을 사용하고 스팸 필터를 잘 구성합니다. 셋째, PGP 공개키 암호화 방식을 제공하는데, 자동화된 스팸 발송자는 PGP 암호화를 사용하지 않습니다. 넷째, Policy에서 보안 취약점 관련 보고서만 받는다는 점을 명확히 명시합니다. 실제로 security.txt를 도입한 대부분의 웹사이트에서 스팸 메일 증가는 미미하지만, 취약점 보고서는 눈에 띄게 증가했다는 피드백을 받고 있습니다.
RFC 9116은 OpenPGP 평문 서명(cleartext signature)으로 security.txt에 전자 서명할 것을 권장하지만(의무 사항은 아님), 이를 통해 연구원은 파일이 웹사이트에서 공식적으로 발행되었으며 공격자에 의해 변조되지 않았음을 검증할 수 있습니다. 방법은 GPG 도구로 파일에 대해 clearsign을 수행하는 것입니다: gpg --clearsign -o security.txt.sig security.txt, 그런 다음 서명된 내용(-----BEGIN PGP SIGNED MESSAGE-----로 시작)을 최종 security.txt 내용으로 사용합니다. 다만 이는 고급 작업이며 대부분의 웹사이트는 서명 없이도 정상적으로 사용할 수 있습니다.
핵심 구성 요건: /.well-known/security.txt 경로에 접근 가능해야 하고, Content-Type이 text/plain으로 반환되어야 하며, HTTPS를 사용해야 하고, 이 경로에 대해 리디렉션을 수행하지 않아야 합니다(특히 다른 도메인으로 리디렉션하지 않아야 함). Nginx는 location 정확 매칭을 사용할 수 있습니다: location = /.well-known/security.txt { default_type text/plain; alias /path/to/security.txt; }；Apache는 .htaccess가 .well-known 디렉터리 접근을 차단하지 않는지 확인합니다；Caddy는 handle_path로 직접 지정하면 됩니다.
매우 권장합니다. 웹사이트 규모와 상관없이 사용자 데이터가 있거나 인터넷에서 서비스를 제공하는 이상 보안 취약점이 존재할 수 있습니다. security.txt 배포 비용은 매우 낮습니다—본 도구로 생성하는 데 2분밖에 걸리지 않으며 파일 하나만 배치하면 됩니다. Google, GitHub 등 대기업이 사용하는 것처럼 개인 개발자와 오픈소스 프로젝트도 마찬가지로 사용할 수 있습니다. 이는 비용 대비 효과가 매우 높은 보안 모범 사례입니다: 비용이 거의 들지 않으면서도 취약점을 발견한 선의의 연구원이 문제를 알릴 수 있는 채널을 마련하여, 그들이 조용히 떠나거나 공개적으로 공개하는 상황을 피할 수 있습니다.
둘 다 /.well-known/(또는 루트 디렉터리)에 위치하는 표준 텍스트 파일이지만 용도는 완전히 다릅니다: robots.txt는 검색 엔진 크롤러를 위한 것으로 어떤 경로를 크롤링하지 말아야 하는지 알려주는 것이고, security.txt는 보안 연구원을 위한 것으로 취약점 발견 시 어떻게 연락해야 하는지 알려주는 것입니다. 하나는 검색 엔진을 대상으로 하고 하나는 보안 연구원을 대상으로 하므로 둘은 상호 보완적이며 충돌하지 않고 동시에 배포할 수 있습니다.
security.txt는 IETF(인터넷 엔지니어링 태스크 포스)가 RFC 9116에서 공식으로 표준화한 웹 보안 모범 사례로, 웹사이트가 보안 연락처 정보를 공개하는 통일되고 표준적인 방법을 제공하기 위한 것입니다. 간단히 말해, 웹사이트의 고정된 경로에 위치하는 텍스트 파일로, 보안 연구원(화이트햇 해커)에게 다음과 같이 알려줍니다: "내 웹사이트에서 보안 취약점을 발견하셨다면, 여기가 우리에게 연락하는 방법입니다. 여기가 우리의 암호화 공개키이고, 여기가 우리의 공개 정책입니다. 당신의 보고를 환영합니다."
security.txt 표준이 나오기 전에는 웹사이트의 보안 연락처 정보가 제각각이었습니다. 보안 연락처가 전혀 없는 웹사이트도 있었고, 구석진 페이지에 숨겨둔 곳도 있었고, 아무도 보지 않는 info@ 메일만 남겨둔 곳도 있었고, LinkedIn에서 힘들게 찾아야 보안 팀에 연락할 수 있는 곳도 있었습니다. 이는 심각한 문제를 초래했습니다: 선의의 보안 연구원이 취약점을 발견해도 올바른 채널을 찾아 보고할 수 없다는 점이었습니다. 그 결과—많은 취약점이 그대로 방치되어 수정되지 않다가 악의적인 해커가 발견하여 악용하는 경우가 많았습니다. security.txt는 바로 이 "마지막 마일" 문제를 해결하기 위해 탄생했습니다.
security.txt 개념은 보안 연구원 EdOverflow와 Yakov Shafranovich가 2017년에 처음 제안했으며, 업계의 광범위한 지지를 빠르게 얻었습니다. 2022년 4월, security.txt는 IETF에 의해 RFC 9116 표준으로 공식 승인되어 국제적으로 인정된 웹 보안 표준이 되었습니다. 현재 Google, GitHub, Meta(Facebook), LinkedIn, Cloudflare 등 대형 IT 기업과 영국 정부, 미국 CISA(사이버보안 및 기반시설 보안국), 프랑스 정부, 이탈리아 정부, 네덜란드 정부, 호주 사이버보안센터 등 정부 기관이 공식 웹사이트에 security.txt를 배포했으며 다른 조직에서도 채택할 것을 공개적으로 권장하고 있습니다.
security.txt 파일의 핵심 디자인은 매우 간결합니다—순수한 텍스트 파일로, 일련의 "필드명: 값" 행으로 구성되어 HTTP 헤더와 유사한 형식입니다. 표준은 두 개의 필수 필드(Contact: 보안 연락처, 여러 개 지정 가능; Expires: 파일 만료 시간)와 여러 선택적 필드(Encryption: PGP 암호화 공개키 URL; Acknowledgments: 감사 페이지 URL; Policy: 취약점 공개 정책 URL; Hiring: 보안 채용 URL; Canonical: 파일 정규 URL; Preferred-Languages: 지원하는 보고 언어; CSAF: 보안 권고 프레임워크 메타데이터 URL)를 정의합니다. 이러한 간단한 형식은 사람과 기계 모두 쉽게 파싱할 수 있게 합니다.
security.txt 배포가 왜 그렇게 중요할까요? 첫째, 취약점 보고의 장벽을 낮춥니다. 보안 연구원이 연락처를 찾는 데 많은 시간을 소비할 필요 없이 한 번에 올바른 보고 채널을 찾을 수 있습니다. 둘째, 조직의 보안에 대한 적극적인 태도를 보여줍니다—security.txt가 있는 웹사이트는 "우리는 보안을 중시하며 책임 있는 보고를 환영합니다"라고 말하는 것과 같습니다. 셋째, 취약점이 공개적으로 공개되거나 악용될 위험을 줄입니다: 연구원이 정식 채널을 가지면 연락이 닿지 않아 Twitter나 GitHub에 취약점을 직접 공개하는 선택을 하지 않을 것입니다. 넷째, 많은 산업 규제 요건(금융, 의료, 정부 등)에서 취약점 공개 채널 구축은 컴플라이언스 요건이 되었습니다.
security.txt를 배포할 때 주의해야 할 몇 가지 핵심 세부 사항이 있습니다. 첫째, 경로가 정확해야 합니다: 표준 경로는 /.well-known/security.txt이며, 폴백으로 루트 디렉터리 /security.txt에 하나 더 배치할 수 있습니다. 여기서 .well-known 디렉터리는 RFC 8615가 정의한 표준 "알려진 리소스" 디렉터리이며, robots.txt 등 다른 표준 파일도 관련 위치에 배치됩니다. 둘째, HTTPS를 통해 제공해야 하며, 평문 HTTP는 안전하지 않은 것으로 간주됩니다. 셋째, Content-Type은 text/plain이어야 하며, text/html이나 다른 유형이면 안 됩니다. 넷째, security.txt에 대해 교차 도메인 리디렉션을 수행하지 마세요—https://example.com/.well-known/security.txt가 https://other-domain.com/security.txt로 리디렉션되면 연구원과 자동화 도구는 이를 의심스러운 것으로 간주합니다. 다섯째, Expires 필드를 설정하고 정기적으로 업데이트하는 것을 잊지 마세요. 만료된 security.txt는 정보가 신뢰할 수 없는 것으로 간주됩니다.
Contact 필드는 security.txt에서 가장 중요한 필드이며, 진정으로 필수 불가결한 유일한 필드입니다(Expires도 필수이지만 타임스탬프일 뿐입니다). Contact는 세 가지 URI 형식을 지원합니다: mailto:는 메일 주소에 사용하고, https://는 웹 링크(예: 보안 보고 양식 페이지)에 사용하며, tel:는 전화번호에 사용합니다. 최소한 하나의 mailto 메일과 하나의 https 양식 링크를 제공할 것을 강력히 권장합니다—양식은 봇 스팸 메일을 방지할 수 있고, 메일은 연구원이 암호화된 보고서를 직접 보내기에 더 편리합니다. 여러 연락처를 여러 행으로 나열할 수 있으며, 예를 들어 보안 팀 메일, 보안 책임자 메일, 제3자 취약점 플랫폼 링크 등을 동시에 제공할 수 있습니다.
Encryption 필드는 선택 사항이지만 실제 운영에서 매우 중요합니다. 보안 연구원이 심각한 취약점(예: 사용자 데이터 유출, 원격 코드 실행)을 발견했을 때, 그들은 평문 메일로 취약점 세부 사항을 보내는 것을 절대 원하지 않을 것입니다—메일은 전송 과정에서 여러 서버를 거치며 어느 한 구간에서도 도청될 수 있기 때문입니다. PGP(Pretty Good Privacy) 공개키 암호화는 업계 표준의 안전한 통신 방식입니다. PGP 키 쌍을 생성하여 공개키를 웹사이트에 배치하고(예: /.well-known/pgp-key.txt), 이 URL을 Encryption 필드에 입력하기만 하면 됩니다. 연구원이 귀하의 공개키로 보고 내용을 암호화하면 해당 개인키를 소지한 사람만 복호화하여 읽을 수 있습니다.
Policy 필드는 귀하의 취약점 공개 정책(Vulnerability Disclosure Policy, VDP) 페이지로 링크되며, 이는 연구원의 신뢰를 구축하는 핵심입니다. 좋은 VDP에는 다음 내용이 명확히 설명되어야 합니다: 테스트 범위(어떤 시스템이 테스트 범위에 포함되고 어떤 시스템이 포함되지 않는지), 허용되는 테스트 방법(예: SQL 인젝션/XSS 테스트는 허용하지만 DDoS/사회 공학/실제 사용자 데이터 접근은 금지), 응답 시간 약속(예: "3영업일 이내에 보고서 수신을 확인하겠습니다"), 버그 바운티 제공 여부, 법적 세이프 하버 약속(규칙을 준수하는 선의의 연구원을 기소하지 않을 것을 명시) 등. 국제적으로 참고할 수 있는 VDP 템플릿이 많이 있으며, 미국 CISA도 오픈소스 VDP 템플릿을 제공하고 있습니다.
보안 연락처 자체 외에도 security.txt에는 몇 가지 "깜짝" 필드가 있습니다. Acknowledgments 필드는 보안 명예의 전당(Hall of Fame)을 구축합니다—귀하가 취약점을 발견하도록 도와준 연구원을 공개적으로 감사하는 것으로, 그들의 노력을 인정하고 커뮤니티를 구축하는 방식입니다. Hiring 필드는 매우 영리한 디자인입니다: 귀하 웹사이트의 취약점을 발견할 수 있는 사람은 그 자체로 우수한 보안 인재이며, security.txt에 채용 링크를 넣는 것은 가장 정확한 보안 인재 채용 채널입니다. 많은 기업이 security.txt를 통해 우수한 보안 엔지니어를 채용했습니다. Canonical 필드는 보안 고려 사항입니다—공격자가 다른 도메인에서 귀하의 security.txt를 위조하는 것을 방지합니다.
흔한 스팸 메일 우려에 대해, 실제로 security.txt를 이미 배포한 대부분의 조직에서 스팸 메일 증가는 미미하다는 피드백을 받고 있습니다. 그 이유는 다음과 같습니다: 첫째, 스팸 발송자는 보통 security.txt를 크롤링하여 메일 주소를 얻지 않습니다; 둘째, 직접 mailto 메일을 넣는 대신 https:// 양식 링크를 사용하고 양식에 캡차를 추가하면 봇을 완전히 차단할 수 있습니다; 셋째, 전용 보안 메일(예: security@)은 보통 엄격한 스팸 필터를 구성합니다. 이에 비해 보안 연락 채널이 부족하여 심각한 취약점 보고를 놓치는 대가는 스팸 메일이 약간 증가하는 것보다 훨씬 큽니다.
본 생성기는 RFC 9116 표준을 엄격히 준수하여 구축되었으며, 모든 출력 형식은 정규화 처리되었습니다: Contact 필드는 접두사를 자동으로 인식하고, Expires 필드는 표준 ISO 8601 UTC 시간 형식을 사용하며, Preferred-Languages는 사용 중인 언어에 따라 자동으로 설정됩니다. 생성된 내용은 복사하여 /.well-known/security.txt 경로에 바로 배포할 수 있으며 어떤 수정도 필요하지 않습니다. 또한 모든 구성은 브라우저 로컬에서 완료되며 어떤 서버에도 전송되지 않습니다—귀하의 보안 연락처 정보는 항상 귀하의 기기에 저장됩니다. security.txt 배포는 5분밖에 걸리지 않지만, 그것이 구축하는 보안 의사소통 채널은 미래에 심각한 보안 사고를 피하는 데 도움이 될 수 있습니다.
다음은 security.txt 표준이 정의한 모든 필드와 그 요건입니다:
| 필드명 | 필수/선택 | 다중 허용? | 값 형식 | 설명 |
|---|---|---|---|---|
| Contact | ✅ 필수 | ✅ 다중 행 허용 | mailto:/https:/tel: URI | 보안 연락처로, 메일, 웹페이지 URL, 전화 세 가지 형식 지원 |
| Expires | ✅ 필수 | ❌ 하나만 | ISO 8601 UTC 시간 | 파일 내용 만료 시간으로, 만료 후 정보가 무효화되었을 수 있음 |
| Encryption | ⬜ 선택 | ✅ 다중 행 허용 | https:// URI | PGP 공개키 위치 URL로, 민감한 취약점 보고서를 암호화하여 전송하는 데 사용 |
| Acknowledgments | ⬜ 선택 | ✅ 다중 행 허용 | https:// URI | 보안 명예의 전당/감사 페이지 URL로, 취약점 신고자를 공개적으로 감사 |
| Policy | ⬜ 선택 | ✅ 다중 행 허용 | https:// URI | 취약점 공개 정책(VDP) 페이지 URL로, 신고 규칙과 범위를 설명 |
| Hiring | ⬜ 선택 | ✅ 다중 행 허용 | https:// URI | 보안 팀 채용 페이지 URL로, 보안 연구원에게 인재 채용 정보 제공 |
| Canonical | ⬜ 선택 | ✅ 다중 행 허용 | https:// URI | security.txt 파일 자체의 정규 URL로, 위조 방지 |
| Preferred-Languages | ⬜ 선택 | ❌ 하나만 | 언어 코드(쉼표로 구분) | 보안 팀이 지원하는 언어로, 예: en, ko, ja |
| CSAF | ⬜ 선택 | ✅ 다중 행 허용 | https:// URI | Common Security Advisory Framework 제공자 메타데이터 URL |
security.txt 내용을 생성한 후 서버에 올바른 접근 경로와 Content-Type을 구성하세요:
| 웹 서버 | 구성 요점 | 주의 사항 |
|---|---|---|
| Nginx | location = /.well-known/security.txt { default_type text/plain; alias /var/www/.well-known/security.txt; add_header Cache-Control "public, max-age=3600"; } | 정확 매칭(=)을 사용하고 default_type을 text/plain으로 지정하여 Nginx가 txt 파일을 바이너리로 처리하지 않도록 하세요 |
| Apache | .well-known 디렉터리가 .htaccess의 Deny 규칙에 의해 차단되지 않도록 확인하고, 파일을 웹사이트 루트 디렉터리의 .well-known 폴더 아래에 배치하면 됩니다 | Apache는 기본적으로 .txt 파일에 text/plain을 반환하지만, mod_rewrite 규칙이 이 경로를 재작성하지 않는지 확인하세요 |
| Caddy | handle_path /.well-known/security.txt { file_server { root /var/www } } | Caddy는 기본적으로 HTTPS를 사용하고 txt 파일 MIME 유형을 올바르게 처리하므로 구성이 가장 간단합니다 |
| Cloudflare Pages/Vercel/Netlify | security.txt를 public/.well-known/security.txt 경로에 배치하면 배포 후 정적 서비스에서 올바르게 접근할 수 있습니다 | 정적 호스팅 플랫폼은 보통 올바른 Content-Type을 자동으로 처리하지만, .well-known 디렉터리가 밑줄로 시작할 때 플랫폼이 무시하지 않는지 확인하세요 |
| CDN/리버스 프록시 | CDN이나 WAF가 security.txt를 차단하거나 너무 오래 캐시하지 않도록 확인하고, Cache-Control을 max-age=3600(1시간)으로 설정할 것을 권장합니다 | security.txt를 업데이트한 후 CDN 캐시를 새로고침하는 것을 잊지 마세요. 그렇지 않으면 연구원이 이전 버전을 볼 수 있습니다 |
본 생성기의 모든 구성 작업은 완전히 귀하의 브라우저 로컬에서 완료되며, 귀하가 입력한 보안 연락처 메일, PGP 키 URL, 채용 링크 등 모든 정보는 어떤 서버에도 전송되지 않으며 수집되거나 저장되지 않습니다. 페이지를 새로고침하거나 닫으면 모든 입력 내용은 즉시 삭제됩니다. 생성된 security.txt 파일 내용은 귀하의 클립보드와 귀하가 배포한 서버에만 존재하며, GeekFormat은 어떤 사본도 보관하지 않습니다.
흔한 원인은 세 가지입니다: 첫째, 파일이 올바른 위치에 없습니다—경로가 웹사이트 루트 디렉터리 아래 .well-known 폴더 안의 security.txt 파일인지 확인하세요(.well-known은 점으로 시작하는 숨은 디렉터리입니다). 둘째, 웹 서버 구성이 점으로 시작하는 디렉터리 접근을 차단하고 있습니다(Apache의 .htaccess나 Nginx의 deny 규칙이 dotfile 디렉터리를 차단할 수 있음). 셋째, Nginx/Apache의 재작성 규칙(예: 프론트엔드 라우팅 history 모드)이 요청을 index.html로 전달하고 있습니다. 해결 방법: 파일 경로를 확인하고 서버 구성에서 /.well-known/security.txt에 대한 location 규칙을 명시적으로 추가하세요.
많은 단일 페이지 애플리케이션(SPA)이나 인증이 있는 웹사이트는 매칭되지 않는 모든 경로를 홈페이지나 로그인 페이지로 리디렉션합니다. 이로 인해 자동화 도구가 security.txt를 찾을 수 없게 됩니다. 해결 방법: 서버 구성에서 /.well-known/security.txt 경로에 예외를 추가하여 이 경로가 SPA 라우팅이나 인증 미들웨어 처리를 거치지 않고 직접 파일 내용을 반환하도록 하세요. 이는 security.txt 배포 시 가장 흔한 함정입니다.
이는 서버가 반환하는 Content-Type이 올바르지 않기 때문으로, text/plain이 아닌 application/octet-stream이나 다른 바이너리 유형으로 설정되어 있을 수 있습니다. 해결 방법: 웹 서버 구성에서 security.txt에 대해 Content-Type을 text/plain; charset=utf-8으로 명시적으로 설정하세요. Nginx는 default_type text/plain이나 add_header Content-Type text/plain을 사용해야 합니다; Apache는 보통 자동으로 처리하지만 문제가 있는 경우 AddType 지시어로 강제 지정할 수 있습니다.
Contact 필드의 값에는 반드시 URI 접두사가 있어야 합니다: 메일 주소는 mailto:로 시작해야 하고(예: mailto:security@example.com, 직접 security@example.com이라고 쓰면 안 됨), 웹페이지 URL은 https://로 시작해야 하며(example.com/security라고만 쓰면 안 됨), 전화번호는 tel:로 시작해야 합니다. 이는 RFC 9116 표준에서 명확히 요구하는 사항입니다—Contact 필드가 여러 연락처 형식을 지원하므로 접두사가 없으면 파서가 유형을 판단할 수 없기 때문입니다.
Expires는 ISO 8601 형식의 UTC 시간을 사용해야 하며, 형식은 YYYY-MM-DDTHH:MM:SSZ이고 끝에는 반드시 Z가 있어 UTC 시간대를 나타내야 합니다(+08:00 등 로컬 시간대 오프셋을 쓰면 안 됨). 올바른 예시: 2027-12-31T23:59:59Z. 2027/12/31, Dec 31 2027, 2027-12-31 23:59:59 등 다른 형식은 표준에 부합하지 않습니다.
다음 사항을 확인하세요: 첫째, HTTPS로 접근하는지 확인하세요(HTTP 접근은 인정되지 않으며 RFC는 HTTPS를 필수로 요구합니다). 둘째, www가 있는 도메인과 없는 도메인 모두에서 올바르게 접근되는지 확인하세요(귀하의 웹사이트에 두 가지 도메인 버전이 모두 존재하는 경우, Canonical 필드에 주 도메인을 선언하고 두 도메인 모두에 security.txt를 배치하거나 올바른 301 리디렉션을 설정하는 것을 권장합니다). 셋째, CDN 캐시가 이전 내용을 지웠는지 확인하세요. 넷째, 서버가 security.txt 경로에서 다른 URL로의 리디렉션(301/302)을 반환하지 않는지 확인하세요—RFC는 리디렉션이 도구에 의해 거부될 수 있다고 규정합니다.
