메인 콘텐츠로 건너뛰기
API 키와 토큰은 매우 신중하게 보호해야 합니다.  이러한 자격 증명은 Developer 앱과, 해당 앱이 대신하여 요청을 보낼 수 있도록 권한을 부여한 X 계정에 직접 연결되어 있습니다. 키가 유출되면 악의적인 사용자가 이를 사용해 귀하의 Developer 앱 또는 그 앱의 승인된 사용자를 대신해 X 엔드포인트에 요청을 보낼 수 있으며, 그 결과 예기치 않게 요청 한도에 도달하거나, 유료 액세스 할당량을 소진하거나, 심지어 Developer 앱이 정지될 수도 있습니다. 다음 석션에서는 API 키와 토큰을 관리할 때 고려해야 할 모범 사례를 안내합니다.

​
API 키와 토큰 재생성

API 키가 노출된 것으로 의심될 경우, 다음 단계를 따라 API 키를 재생성하세요.
  1. 개발자 포털의 “Projects and Apps” 페이지로 이동합니다.
  2. 해당 App 옆의 “Keys and tokens” 아이콘(🗝)을 클릭합니다.
  3. 재생성하려는 키와 토큰 묶음 옆의 “Regenerate” 버튼을 클릭합니다. 
액세스 토큰 또는 베어러 토큰을 프로그래밍 방식으로 재생성하려면 인증 엔드포인트를 사용하세요.

​
시크릿을 중앙에서 관리하는 파일 사용

시크릿을 보관하기 위해 .env 파일이나 .yaml 파일 같은 전용 파일을 사용하는 것도 도움이 될 수 있지만, 이를 실수로 Git 저장소에 커밋하지 않도록 반드시 강력한 .gitignore를 준비하세요. 

​
환경 변수

환경 변수를 활용하는 코드를 작성하면 유용할 수 있습니다.  Python으로 작성된 예시는 다음과 같습니다: 
import os

consumer_key = os.environ.get("CONSUMER_KEY")

consumer_secret = os.environ.get("CONSUMER_SECRET")
터미널에서 다음과 같이 입력하세요: 
export CONSUMER_KEY='xxxxxxxxxxxxxxxxxxx'
export CONSUMER_SECRET='xxxxxxxxxxxxxxxxxxxxxxx'

​
소스 코드와 버전 관리

개발자가 저지르는 가장 흔한 보안 실수는 GitHub 및 Bitbucket 같은 접근 가능한 버전 관리 시스템에 API 키와 토큰을 커밋하는 것입니다. 이러한 코드 저장소의 상당수는 공개되어 있습니다. 공개 저장소에서 이 실수가 워낙 빈번해 API 키를 긁어모으는 수익성 높은 봇들까지 존재합니다.
  • 서버 환경 변수를 사용하세요. API 키를 환경 변수에 저장하면 코드와 버전 관리에서 분리할 수 있습니다. 또한 환경별로 다른 키를 손쉽게 사용할 수 있습니다.
  • 소스 관리에서 제외되는 구성 파일을 사용하세요. 버전 관리에서 추적되지 않도록 해당 파일 이름을 .gitignore 파일에 추가하세요.
  • 버전 관리를 사용한 뒤 코드에서 API 키를 제거하더라도, 코드베이스의 이전 버전에 접근하면 여전히 키에 접근할 수 있는 가능성이 큽니다. 다음 섹션에 설명된 대로 API 키를 재발급하세요.

​
데이터베이스

액세스 토큰을 데이터베이스에 저장해야 한다면, 다음을 유의하세요:
  • 데이터베이스 접근을 제한해 액세스 토큰을 토큰 소유자만 읽을 수 있도록 하세요.
  • 액세스 토큰용 데이터베이스 테이블의 편집/쓰기 권한을 제한하세요 — 이는 키 관리 시스템으로 자동화되어야 합니다.
  • 어떤 데이터 저장소에 저장하기 전에 액세스 토큰을 암호화하세요.

​
비밀번호 관리 도구

1Password 또는 LastPass와 같은 비밀번호 관리 도구는 키와 토큰을 안전하게 보관하는 데 도움이 될 수 있습니다. 팀이 함께 사용하는 공유 비밀번호 관리 도구 내에서 이를 공유하는 일은 피하는 것이 좋습니다.

​
웹 스토리지 & 쿠키

웹 스토리지는 LocalStorage와 SessionStorage의 두 가지 유형이 있습니다. 이는 쿠키 사용을 개선하기 위해 만들어졌으며, 웹 스토리지의 저장 용량이 쿠키보다 훨씬 크기 때문입니다. 다만, 각 저장 방식에는 서로 다른 장단점이 있습니다.   웹 스토리지: LocalStorage 로컬 웹 스토리지에 저장된 데이터는 지속됩니다. 즉, 명시적으로 삭제하지 않는 한 유지됩니다. 프로젝트 요구 사항에 따라 이는 장점이 될 수 있습니다. 다만 LocalStorage 사용 시에는 주의가 필요합니다. 해당 데이터의 변경이나 추가 내용이 해당 웹페이지에 대한 이후 모든 방문에서 계속 반영되기 때문입니다. 일반적으로는 LocalStorage 사용을 권장하지 않지만, 일부 예외가 있을 수 있습니다. LocalStorage를 사용하기로 했다면 동일 출처 정책을 지원한다는 점을 알아두세요. 따라서 여기에 저장된 데이터는 동일한 출처를 통해서만 접근할 수 있습니다. 또한 LocalStorage를 사용하면 모든 HTTP 요청마다 데이터를 서버로 다시 전송할 필요가 없어 클라이언트-서버 트래픽이 줄어드는 성능상 이점이 있습니다.   웹 스토리지: SessionStorage SessionStorage는 LocalStorage와 유사하지만, 핵심 차이는 SessionStorage가 비지속적이라는 점입니다. SessionStorage에 쓰기를 수행한 창(또는 브라우저에 따라 탭)이 닫히면 데이터가 사라집니다. 이는 사용자 세션 내에서 토큰의 읽기 접근을 제한하는 데 유용합니다. 보안 관점에서는 일반적으로 LocalStorage보다 SessionStorage가 더 바람직합니다. LocalStorage와 마찬가지로 동일 출처 정책 지원과 클라이언트-서버 트래픽 감소의 이점이 SessionStorage에도 적용됩니다.   쿠키 쿠키는 세션 데이터를 저장하는 전통적인 방식입니다. 각 쿠키에 만료 시간을 설정할 수 있어, 철회 용이성과 접근 제한을 쉽게 구현할 수 있습니다. 그러나 쿠키를 사용하면 모든 HTTP 요청마다 데이터가 서버로 전송되므로 클라이언트-서버 트래픽이 확실히 증가합니다. 쿠키를 사용하기로 했다면 세션 하이재킹에 대비해야 합니다. 기본적으로 쿠키는 HTTP에서 평문으로 전송되므로, 패킷 스니핑 및/또는 중간자 공격에 노출되어 공격자가 트래픽을 변조할 수 있습니다. 데이터 전송 중 보호를 위해서는 항상 HTTPS를 강제해야 합니다. 이는 기밀성, 무결성(데이터의), 그리고 인증을 제공합니다. 다만 웹 애플리케이션이나 사이트가 HTTP와 HTTPS 모두로 접근 가능하다면, 쿠키에 ‘Secure’ 플래그도 사용해야 합니다. 이렇게 하면 공격자가 사용자에게 사이트의 HTTP 버전 링크를 보내 그로 인해 발생한 HTTP 요청을 도청하는 것을 방지할 수 있습니다. 쿠키 사용 시 세션 하이재킹에 대한 또 다른 보조 방어책은 고위험 작업을 수행하기 전에 사용자의 신원을 다시 검증하는 것입니다. 쿠키 보안을 강화하기 위해 고려할 또 다른 플래그는 ‘HttpOnly’ 플래그입니다. 이 플래그는 해당 쿠키가 지정된 서버에서만 접근 가능하도록 브라우저에 지시합니다. 클라이언트 측 스크립트의 접근 시도는 이 플래그에 의해 차단되므로, 대부분의 크로스사이트 스크립팅(XSS) 공격에 대비하는 데 도움이 됩니다.