최소 이벤트 수 구독
필요한 웹후크 이벤트만 구독해야 합니다. 그러면 서버에서 수행해야 하는 작업의 양이 줄어듭니다. 이벤트 구독에 대한 자세한 내용은 웹후크 만들기 및 웹후크 편집하기을(를) 참조하세요.
웹후크 비밀 사용
Warning
중요한 정보가 실수로 노출되지 않도록 하려면 페이로드 URL에 중요한 정보를 포함하지 않도록 주의하세요. 여기에는 사용자 고유의 API 키 및 기타 인증 자격 증명이 포함됩니다. 대신 웹후크 제공이 GitHub에서 전송되었지만 변조되지 않았는지 확인하려면 웹후크 비밀을 사용합니다. 자세한 내용은 웹후크 제공 유효성 검사하기을(를) 참조하세요.
웹후크 비밀은 엔트로피가 높은 임의의 텍스트 문자열이어야 합니다. 서버에서 액세스할 수 있는 방식으로 웹후크 비밀을 안전하게 저장해야 합니다.
HTTPS 및 SSL 확인 사용
서버에서 HTTPS 연결을 사용하는지 확인해야 합니다. 기본적으로 GitHub은(는) 웹후크를 제공할 때 SSL 인증서를 확인합니다. GitHub은(는) SSL 확인을 사용하도록 설정하는 것이 좋습니다.
GitHub의 IP 주소 허용
서버에 대한 IP 허용 목록을 설정하고 웹후크 제공에 GitHub에서 사용하는 IP 주소를 추가할 수 있습니다. 이를 통해 서버에 대한 스푸핑된 요청을 차단할 수 있습니다.
GET /meta 끝점을 사용하여 GitHub IP 주소의 현재 목록을 찾을 수 있습니다. 자세한 내용은 메타 데이터에 대한 REST API 엔드포인트을(를) 참조하세요. GitHub는 때때로 IP 주소를 변경하기 때문에 IP 허용 목록을 주기적으로 업데이트해야 합니다.
자세한 내용은 GitHub IP 주소 정보을(를) 참조하세요.
10 초 내에 응답
서버는 웹후크 제공을 받은 후 10 초 내에 2XX 응답으로 응답해야 합니다. 서버가 응답하는 데 이보다 더 오래 걸리면 GitHub가 연결을 종료하고 제공을 실패로 간주합니다.
적시에 응답하기 위해 웹후크 페이로드를 비동기적으로 처리하도록 큐를 설정할 수 있습니다. 서버는 웹후크를 받을 때 응답한 다음 이후 웹후크 제공을 차단하지 않고 백그라운드에서 페이로드를 처리할 수 있습니다. 예를 들어 Hookdeck 같은 서비스 또는 Resque(Ruby), RQ(Python) 또는 RabbitMQ(Java)와 같은 라이브러리를 사용할 수 있습니다.
이벤트를 처리하기 전에 이벤트 유형 및 작업 확인
여러 가지 웹후크 이벤트 유형이 있으며, 각 이벤트에는 여러 작업이 있을 수 있습니다. GitHub은(는) 기존 이벤트 형식에 새 이벤트 유형과 새 작업을 계속 추가합니다. 애플리케이션은 페이로드를 처리하기 전에 웹후크 페이로드의 이벤트 유형 및 작업을 확인합니다. 이벤트 유형을 확인하기 위해 X-GitHub-Event 요청 헤더를 사용할 수 있습니다. 작업 유형을 확인하기 위해 이벤트 페이로드에서 최상위 action 키를 사용할 수 있습니다.
누락된 제공 다시 제공하기
서버가 다운된 경우 서버가 백업되면 누락된 웹후크를 다시 제공해야 합니다. 자세한 내용은 웹후크 다시 제공을(를) 참조하세요.
X-GitHub-Delivery 머리글 사용
리플레이 공격에서 잘못된 행위자가 웹후크 제공을 가로채 해당 제공을 다시 보냅니다. 리플레이 공격으로부터 보호하려면 X-GitHub-Delivery 머리글을 사용하여 각 배달이 이벤트마다 고유한지 확인할 수 있습니다.
Note
다시 제공을 요청하는 경우, X-GitHub-Delivery 머리글은 원래 제공에 있던 것과 동일합니다.