메인 콘텐츠로 건너뛰기
API 키와 토큰은 각별히 주의해서 보호해야 합니다.  이 자격 증명은 developer App 자체와, 해당 App이 대신 요청을 보내도록 승인을 받은 X 계정에 직접 연결되어 있습니다. 키가 유출되면, 악의적인 사용자가 이를 이용해 developer App 또는 그 App이 승인한 사용자들을 대신해 X 엔드포인트에 요청을 보낼 수 있습니다. 이렇게 되면 예기치 않게 요청 한도에 도달하거나, 유료 접근 할당량을 모두 소진하게 되거나, 심지어 developer App이 정지될 수도 있습니다. 다음 섹션에서는 API 키와 토큰을 관리할 때 고려해야 할 모범 사례를 설명합니다.

​
API 키 및 토큰 재생성

API 키가 노출되었다고 생각되는 경우, 다음 단계를 따라 API 키를 재생성해야 합니다.
  1. 개발자 콘솔의 “Apps” 페이지로 이동합니다.
  2. 해당 App 옆에 있는 “Keys and tokens” 아이콘(🗝)을 클릭합니다.
  3. 재생성하려는 키와 토큰 세트 옆에 있는 “Regenerate” 버튼을 클릭합니다. 
Access Token 또는 Bearer 토큰을 프로그래밍 방식으로 재생성하려면 인증 엔드포인트를 사용하면 됩니다.

​
비밀 정보를 위한 단일 파일 사용

.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 키에 여전히 접근할 수 있는 경우가 많습니다. 다음 섹션에 설명된 대로 API 키를 다시 생성하세요.

​
데이터베이스

액세스 토큰을 데이터베이스에 저장해야 하는 경우, 다음 사항을 유의하세요:
  • 액세스 토큰을 해당 토큰의 소유자만 읽을 수 있도록 데이터베이스 접근을 제한합니다.
  • 액세스 토큰용 데이터베이스 테이블에 대한 수정/쓰기 권한을 제한합니다 - 이는 키 관리 시스템을 통해 자동화해야 합니다.
  • 어떤 데이터 저장소에 저장하든, 저장하기 전에 액세스 토큰을 반드시 암호화합니다.

​
비밀번호 관리 도구

1password나 Last Pass와 같은 비밀번호 관리 도구는 키와 토큰을 안전한 곳에 보관하는 데 유용합니다. 다만 팀에서 함께 사용하는 공유 비밀번호 관리 도구 안에서 이러한 정보를 공유하는 것은 피하는 것이 좋습니다.

​
웹 스토리지 & 쿠키

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