보안 및 설정

API 키 보호의 핵심은 노출하지 않고, 최소 권한을 사용하고, 정기적으로 교체하며, 사용을 추적 가능하게 유지하는 것입니다.

API 키를 어떻게 관리하고 보호하나요?

권장 방법:

• 공개 저장소, 프런트엔드 페이지, 모바일 패키지 또는 스크린샷에 키를 넣지 마세요.
• 서버에서 환경 변수나 비밀 관리 시스템으로 키를 읽으세요.
• 개발, 테스트 및 운영에 서로 다른 키를 만드세요.
• 서비스나 앱별로 키를 분리하여 추적성과 격리를 개선하세요.
• 필요에 따라 모델 권한을 설정하고 적절한 경우 만료일을 지정하세요.
• 정기적으로 교체하고 인력 변경, 서비스 종료 또는 유출 의심 시 즉시 교체하세요.

키가 유출되었을 수 있다면:

1. 기존 키를 즉시 비활성화, 삭제 또는 교체하세요.
2. 새 키를 만들고 모든 종속 서비스를 갱신하세요.
3. 최근 사용량, 잔액 변동 및 비정상 지출을 확인하세요.
4. 모델 권한을 줄이고 더 짧은 유효기간을 고려하세요.
5. 저장소, 로그, CI 설정 또는 외부 클라이언트 같은 유출 경로를 확인하세요.

키 유출은 무단 호출과 금전 손실을 일으킬 수 있습니다. 테스트 키도 운영 환경의 비밀처럼 보호해야 합니다.

생성 후 전체 API 키를 다시 볼 수 있나요?

아니요. 전체 키는 성공적인 생성 과정에서만 표시됩니다. 이후 콘솔에는 가려진 미리보기만 표시됩니다.

생성 창을 닫기 전에 서버 측 환경 변수나 비밀 관리 시스템에 저장하세요. 분실한 키는 사용자 또는 관리자 API로 복구할 수 없습니다. 대체 키를 만들고 호출자를 갱신한 다음 기존 키를 삭제하세요. 문서의 AI 통합 템플릿은 <API_KEY> 자리표시자를 사용하며 과거 키를 불러오지 않습니다.

API 키를 어떻게 전송하나요?

요청 헤더로만 전송하세요. 권장 형식은 다음과 같습니다.

Authorization: Bearer YOUR_API_KEY

다음도 사용할 수 있습니다.

X-API-Key: YOUR_API_KEY

RequestBeam API 자격 증명을 URL 조회 매개변수에 넣지 마세요. 자격 증명 형식의 이름(apiKey, api_key, apikey, x-api-key, key)은 보통 HTTP 400을 발생시킵니다. 제한적인 Similarweb 업무 매개변수 예외는 GET 요청에만 적용됩니다: /v1/similarweb/websites/backlinks는 대문자 Key 필드의 호스트 이름 하나를 허용합니다. /v1/similarweb/websites/outgoing-traffic, /websites/incoming-referrals 및 /websites/similar-sites/suggestions는 소문자 key 필드의 호스트 이름 하나를 허용합니다 (모두 /v1/similarweb 아래). 이 필드는 대상 웹사이트를 지정하며 API 자격 증명이 아닙니다. 유효한 호스트 이름이어야 합니다. 중복, 잘못된 대소문자, 자격 증명처럼 보이는 값 및 추가 자격 증명 조회 필드는 계속 차단됩니다. Similarweb 경로를 포함하여 항상 요청 헤더로 인증하세요. Similarweb 요청 예제를 참조하세요.

이 규칙은 OAuth token, apiKeyId, username 또는 pagination_token 같은 다른 업무 매개변수에는 영향을 주지 않습니다.