AEO WEB TOOL
security.txt 생성기
security.txt 는 사이트의 취약점을 발견한 사람이 어디로 연락해야 하는지 적어 두는 표준 파일입니다. RFC 9116 이 요구하는 필수 항목을 빠뜨리지 않도록 검사하며, 만료일을 자동으로 계산해 넣어 줍니다.
무료 · 가입 불필요브라우저에서 처리RFC 9116
연락 정보 입력
Contact 와 Expires 만 있으면 유효한 파일이 됩니다.
이메일만 적으면
mailto: 를 자동으로 붙입니다. 신고 폼 주소나 전화번호(tel:)도 됩니다.
1년 이내 권장. 만료 전에 갱신해야 합니다.
신고를 받을 수 있는 언어입니다.
입력하면
/.well-known/security.txt 경로를 붙여 Canonical 줄을 만듭니다.
결과 - security.txt
올리는 위치: https://example.com/.well-known/security.txt 입니다. 점으로 시작하는 폴더라 서버 설정에 따라 차단될 수 있으니 올린 뒤 브라우저로 직접 열어 확인하세요.
security.txt 는 왜 필요한가요?
보안 취약점을 발견한 사람이 가장 먼저 하는 일은 연락처를 찾는 것입니다. 그런데 대부분의 사이트에서 이 일이 놀랄 만큼 어렵습니다. 고객센터 문의 폼으로 보내면 상담원이 무슨 말인지 몰라 묻히고, 대표 이메일은 확인하는 사람이 없습니다. 연락이 닿지 않으면 발견자는 공개적으로 알리거나 그냥 무시하게 되는데, 어느 쪽도 운영자에게 유리하지 않습니다.
security.txt 는 이 문제를 파일 하나로 해결합니다. /.well-known/security.txt 라는 약속된 경로에 연락처를 적어 두면, 찾는 사람은 그 주소만 확인하면 됩니다. 2022년 RFC 9116 으로 표준이 되었습니다.
항목별 의미
| 항목 | 필수 | 의미 |
|---|---|---|
Contact | 필수 | 신고를 받을 곳. mailto:, https://, tel: 중 아무 것이나. 여러 줄 가능하며 위에 적은 것이 우선순위가 높습니다. |
Expires | 필수 | 이 파일 내용을 언제까지 신뢰할 수 있는지. 지나면 무효로 취급됩니다. |
Preferred-Languages | 선택 | 신고를 처리할 수 있는 언어. 우선순위 없이 나열합니다. |
Canonical | 선택 | 이 파일이 놓일 정식 주소. 다른 곳에 복사된 위조본과 구분됩니다. |
Policy | 선택 | 신고 처리 정책·포상 규정 문서 주소. |
Acknowledgments | 선택 | 제보자에게 감사를 표시하는 페이지. 제보 동기를 높입니다. |
Encryption | 선택 | 암호화 신고용 공개키 주소. 키 자체가 아니라 키가 있는 URL 을 적습니다. |
Hiring | 선택 | 보안 관련 채용 페이지. |
운영할 때 주의할 점
- 만료일 관리가 핵심입니다 - 만료된 security.txt 는 "이 정보는 더 이상 유효하지 않다"고 선언하는 것과 같습니다. 달력에 갱신 일정을 등록해 두세요.
- 역할 주소를 쓰세요 - 개인 이메일 대신 security@ 처럼 담당자가 바뀌어도 유지되는 주소가 안전합니다.
- 받을 준비가 된 창구여야 합니다 - 적어 둔 주소로 실제 신고가 왔을 때 읽고 대응할 사람이 있어야 의미가 있습니다.
- 포상 여부를 미리 밝히세요 - Policy 문서에 보상 정책이 있는지 없는지 적어 두면 불필요한 분쟁이 줄어듭니다.
- 접근 가능한지 확인하세요 -
.well-known은 점으로 시작해 일부 서버 설정에서 차단됩니다. 올린 뒤 반드시 브라우저로 열어 보세요.
자주 묻는 질문
- security.txt 가 AEO 점수에 포함되나요?
- 포함되지 않습니다. 채점 모델 v3.1에서 본점 항목에서 제외하고 비채점 체크리스트로 옮겼습니다. 모든 사이트에 공통으로 요구할 근거가 부족했기 때문입니다. 개인 블로그에 취약점 신고 창구가 없다고 해서 AI 검색 대응이 부족하다고 볼 수는 없습니다. 다만 파일이 있는 경우에는 필수 필드와 만료 여부를 확인해 알려 줍니다 - 만료된 파일은 없는 것보다 나쁠 수 있기 때문입니다.
- Expires 가 왜 필수인가요?
- 연락처가 낡은 채 방치되는 것을 막기 위해서입니다. security.txt 는 한 번 올려 두고 잊기 쉬운 파일인데, 담당자가 퇴사하거나 이메일이 폐기되면 신고가 아무에게도 닿지 않습니다. RFC 9116 은 Expires 를 필수로 요구하고 1년 이내를 권장합니다. 만료일이 지난 파일의 정보는 신뢰하지 않는 것이 규정된 동작입니다.
- 어디에 올려야 하나요?
/.well-known/security.txt가 정식 경로입니다. 루트의/security.txt는 하위 호환을 위해 허용되지만 권장되지 않습니다. 점으로 시작하는 폴더라 일부 서버 설정에서 접근이 차단돼 있을 수 있으니, 올린 뒤 브라우저로 직접 열어 확인하세요.- 연락처를 공개하면 스팸이 오지 않나요?
- 어느 정도 옵니다. 그래서 개인 이메일 대신 security@ 같은 역할 주소를 쓰거나, 이메일 대신 신고 폼 URL 을 Contact 로 지정하는 방법을 권합니다. Contact 에는 mailto:, https://, tel: 중 아무 것이나 쓸 수 있고 여러 개를 나열할 수도 있습니다.
- 꼭 만들어야 하나요?
- 의무는 아닙니다. 다만 일정 규모 이상의 서비스, 특히 개인정보나 결제를 다루는 사이트라면 두는 편이 낫습니다. 취약점을 발견한 사람이 연락할 곳을 찾지 못하면 공개적으로 알리거나 방치하게 되는데, 어느 쪽도 운영자에게 좋지 않습니다. 파일 하나로 그 경로를 만들어 두는 일입니다.