[IT] 서버연동시 api key가 필요하다면 절대로 앱에 하드코딩 하지마라

서버를 통해 API 키나 민감 데이터를 주고받는다면, 그 통신 채널도 반드시 안전해야 합니다.

---

✅ 안전한 채널을 구성하려면?

1. HTTPS (SSL/TLS) 사용 – 필수

• HTTP는 절대 금지, 반드시 https:// 로만 통신해야 합니다.
• TLS 1.2 이상을 사용하세요.
• 서버에 유효한 SSL 인증서가 설치되어 있어야 합니다.
• 예: Let's Encrypt 같은 무료 인증서 사용 가능

📌 앱에서 HTTP로 요청하면 Google Play에 등록도 제한됩니다 (API 28+ 이상).

---

2. Certificate Pinning (공개키 고정) – 선택적 강화

• 서버의 인증서 또는 공개키를 앱에 저장해서, 중간자(MITM) 공격을 방지하는 기술.
• 일반적으로 통신 중 공격자가 자신만의 인증서를 껴넣어 중간에 낚아채는 걸 막기 위해 사용됨.
• 구현 방법:
  • OkHttp, Retrofit 등에서 핀 고정 가능
  • 예: okhttp3.CertificatePinner

 

CertificatePinnercertificatePinner=newCertificatePinner.Builder() .add("api.example.com", "sha256/AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA=") .build(); OkHttpClientclient=newOkHttpClient.Builder() .certificatePinner(certificatePinner) .build();

📌 단점은 서버 인증서가 바뀌면 앱도 업데이트해야 한다는 것.

---

3. JWT 또는 세션 기반 인증 사용

• 민감 데이터는 인증된 사용자만 요청할 수 있도록 서버에 인증 로직을 넣어야 합니다.
• 인증 방식 예:
  • OAuth2 + JWT
  • Firebase Auth
  • 자체 로그인 + 세션/토큰

[사용자 로그인] → [토큰 발급] → [앱 저장] → [API 요청 시 토큰 첨부]

---

4. 서버 사이드 Rate Limiting / Abuse Detection

• 누가 서버에 API 키를 빼가더라도, 너무 자주 요청하면 차단되게 설정
• 예:
  • IP 단위 제한
  • 사용자 토큰 단위 제한
  • Cloudflare / AWS WAF 같은 보안 서비스 사용

---

5. 로그/디버깅 시 키 노출 주의

• 서버 로그, 앱 로그, 크래시 리포트에 키나 민감 정보가 찍히지 않게 필터링해야 합니다.

---

🔐 안전한 통신 흐름 예시

 

[📱 앱] ⇅ HTTPS [🌐 내 서버 (API 키 보유)] ⇅ HTTPS [💻 외부 API 서버 (예: OpenAI, Stripe 등)]

• 클라이언트는 오직 내 서버와만 안전하게 통신
• API 키는 외부에 절대 노출되지 않음
• 통신은 HTTPS + 인증 + (Certificate Pinning)으로 보호됨

---

✅ 결론

"서버를 통해 받아도, 그 서버와의 통신이 안전해야 진짜 보안이다."

• HTTPS는 기본 중 기본입니다.
• 중간자 공격 방지하려면 Certificate Pinning 고려
• 사용자 인증 & 요청 제한으로 추가 방어
• 안전한 서버 구성 없이는 API 키 숨기는 것도 무의미

----

 

✅ API 키 보호 방법 & 통신 보안 전략 – 장단점 요약표

방법설명장점단점보안 수준

1. 앱 내 하드코딩 (Java/Kotlin)	키를 코드에 직접 넣음	구현 가장 쉬움	APK 디컴파일로 바로 노출	🔴 매우 낮음
2. JNI/NDK (C/C++로 키 숨김)	키를 Native 라이브러리에 넣음	Java보단 추출 어렵다	리버스 엔지니어링 가능	🟠 낮음~중간
3. 앱 → 서버 → 외부 API (프록시 서버)	키는 서버에서만 사용, 앱은 키 몰라도 됨	키 완전 숨김, 키 변경도 쉬움	서버 운영 필요	🟢 높음
4. Firebase Remote Config / Secure Key Delivery	앱 실행 시 서버에서 키 받아옴	키 변경 쉬움, 코드에 없음	여전히 앱에서 수신 → 노출 가능	🟡 중간
5. HTTPS (SSL/TLS) 통신	서버와의 기본적인 안전 통신	기본 보호 제공, 필요조건	중간자 공격에는 취약 (MITM 가능성)	🟢 높음 (기본)
6. Certificate Pinning	앱에 서버 인증서 핀 저장	MITM 공격 방어	인증서 변경 시 앱도 재배포	🟢 매우 높음
7. 사용자 인증 + JWT / OAuth	로그인한 사용자만 요청 가능	사용자별 요청 통제, 추가 보안	인증 로직 추가 필요	🟢 높음
8. Rate Limiting / Abuse Detection	서버에서 이상 요청 차단	비정상 접근 제한 가능	정상 사용자에게도 제한될 수 있음	🟢 보조 수단

 

---

📌 추천 조합 (실제 앱 기준)

요소추천 조합

API 키 위치	서버에서만 보관 (클라이언트는 몰라도 됨)
클라이언트 ↔ 서버 통신	HTTPS + 인증 토큰
보안 강화	Certificate Pinning + JWT 인증 + Rate Limiting
클라이언트 보호	앱 코드 난독화 + NDK 사용 (추가 보안 수단)

 

---

🔐 요약 정리

• 가장 안전한 방식은:
  👉 앱에는 키를 절대 넣지 않고, 키는 서버에서만 보관 & 사용.
  👉 HTTPS + 인증 + 핀 고정 등으로 통신도 보호.
• JNI/NDK, 난독화는 완벽한 보안이 아닌 보조 수단입니다.
• 진짜 중요한 건 API 키가 클라이언트에 없어야 한다는 것입니다.