웹후크 사용에 대한 모범 사례

최소 이벤트 수 구독

필요한 웹후크 이벤트만 구독해야 합니다. 그러면 서버에서 수행해야 하는 작업의 양이 줄어듭니다. 이벤트 구독에 대한 자세한 내용은 웹후크 만들기 및 웹후크 편집하기을(를) 참조하세요.

웹후크 비밀 사용

웹후크 비밀은 엔트로피가 높은 임의의 텍스트 문자열이어야 합니다. 서버에서 액세스할 수 있는 방식으로 웹후크 비밀을 안전하게 저장해야 합니다.

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 머리글을 사용하여 각 배달이 이벤트마다 고유한지 확인할 수 있습니다.

추가 참고 자료

• REST API 사용에 대한 모범 사례
• GitHub App을 만드는 모범 사례