내 API 응답에 사용자 전화번호가 담겨 나오고 있지 않나요

1. API 응답에서 생각보다 자주 놓치는 부분

1) 전화번호, 이메일, 주소가 그대로 내려오는 경우

API응답보안을 점검하다 보면 가장 먼저 보게 되는 문제가 민감한 값이 응답에 그대로 포함되는 경우입니다. 화면에는 보이지 않더라도 REST API가 반환하는 JSON 안에 사용자 전화번호, 이메일, 주소가 들어 있으면 외부에서 쉽게 확인할 수 있습니다. 이런 정보는 단순 편의 때문에 넣어둔 경우가 많지만, 누적되면 개인정보노출로 이어질 수 있습니다.

2) 개발 단계에서는 괜찮아 보여도 운영에서는 달라집니다

테스트 중에는 “어차피 내부 시스템에서만 본다”라고 생각하기 쉽습니다. 하지만 운영 환경에서는 브라우저 개발자도구, 프록시 도구, 로그 수집 과정 등을 통해 응답 값이 노출될 수 있습니다. 특히 인증이 붙은 REST API라도 응답 내용 자체가 안전한 것은 아니기 때문에, 민감정보유출 관점에서 한 번 더 확인할 필요가 있습니다.

3) 응답에 넣어도 되는 정보와 아닌 정보

응답에는 보통 서비스 화면을 구성하는 데 꼭 필요한 값만 넣는 것이 좋습니다. 예를 들어 마스킹되지 않은 전화번호, 생년월일, 내부 식별자, 비공개 메모 같은 값은 목적 없이 내려가지 않는지 살펴봐야 합니다. API응답보안은 거창한 설정보다도 이런 기본 원칙을 지키는 것에서 시작하는 경우가 많습니다.

2. 왜 API 응답 보안이 중요한가

1) 한 번 노출되면 복구가 어렵습니다

웹페이지에서 한 번 숨긴 정보와 달리, API 응답에 포함된 값은 로그, 캐시, 브라우저 기록, 공유 링크 등을 통해 여러 경로로 남을 수 있습니다. 특히 사용자 전화번호처럼 개인을 직접 식별할 수 있는 정보는 개인정보노출 문제로 바로 이어질 수 있습니다. 그래서 민감정보유출은 사후 대응보다 사전 점검이 더 중요합니다.

2) 권한이 있는 사용자에게만 보여도 안전하지 않습니다

내부 사용자에게만 보이는 응답이라고 해도, 꼭 필요한 범위를 넘어서면 문제가 됩니다. 예를 들어 주문 조회 API에서 배송 연락처 전체를 반환하거나, 관리자용 API가 아닌데도 내부 메모가 같이 내려오는 식입니다. 이런 경우에는 인증이 되어 있어도 API응답보안이 충분하다고 보기 어렵습니다.

3) REST API는 구조상 재사용이 많아 더 주의가 필요합니다

REST API는 한 번 만들어두면 여러 화면이나 서비스에서 재사용하는 경우가 많습니다. 그래서 초기에 편의상 넣은 값이 나중에 다른 화면까지 그대로 퍼질 수 있습니다. 결과적으로 응답 구조가 커질수록 민감정보유출 가능성도 함께 커지기 때문에, 설계 단계부터 범위를 분리해 두는 편이 좋습니다.

3. 실제로 확인해야 하는 대표 항목

1) HTTPS와 인증서 상태

기본이지만 가장 먼저 봐야 하는 부분입니다. HTTPS가 적용되어 있지 않거나 인증서 설정이 불완전하면, 응답 내용이 전송 과정에서 노출될 위험이 커집니다. API응답보안은 응답 필드만 보는 것이 아니라 전달 경로까지 함께 보는 관점이 필요합니다.

2) 보안 헤더와 브라우저 노출 가능성

브라우저에서 호출되는 API는 보안 헤더 설정에 따라 노출 방식이 달라질 수 있습니다. 캐시 정책, 콘텐츠 관련 설정, 클릭재킹 방지 설정 등이 충분하지 않으면 예상하지 못한 방식으로 정보가 남을 수 있습니다. 특히 REST API를 프론트엔드와 함께 운영한다면 이 부분을 함께 점검하는 것이 좋습니다.

3) CORS, 쿠키, API 접근 범위

외부 도메인에서 접근 가능한 REST API라면 CORS 설정이 너무 넓지 않은지 확인해야 합니다. 쿠키가 불필요하게 자동 전송되거나, 접근 범위가 과도하게 열려 있으면 민감한 정보가 더 쉽게 노출될 수 있습니다. 민감정보유출은 응답 본문뿐 아니라 접근 정책에서도 생기는 경우가 많습니다.

4. 브라우저에서 직접 드러나는 문제들

1) Mixed Content와 잘못된 리소스 호출

페이지는 HTTPS인데 API 일부가 HTTP로 호출되면 Mixed Content 문제가 생길 수 있습니다. 이 경우 중간에서 응답이 노출되거나 차단되어 서비스가 불안정해질 수 있습니다. API응답보안을 보려면 단순히 서버 설정만이 아니라 실제 브라우저 동작도 확인해야 합니다.

2) XSS와 연동된 응답 노출

응답 자체는 정상이어도, 화면 렌더링 과정에서 스크립트가 섞이면 민감정보유출로 연결될 수 있습니다. 예를 들어 API에서 받아온 사용자 이름이나 메모가 제대로 이스케이프되지 않으면 XSS 문제가 생길 수 있습니다. 이런 이유로 REST API 응답은 전달 형식과 함께 사용 위치까지 고려해야 합니다.

3) 개발 중에는 안 보이던 노출이 운영에서 보이는 경우

로컬 환경에서는 보안 정책이 느슨해서 문제가 안 보였는데, 운영 브라우저에서는 쿠키나 헤더 처리 방식이 달라 예상치 못한 값이 드러나는 경우가 있습니다. 개인정보노출은 이런 환경 차이에서 발견되는 경우도 적지 않습니다. 따라서 실제 운영에 가까운 조건에서 점검하는 습관이 필요합니다.

5. 개인정보가 들어가는 API를 설계할 때의 기준

1) 응답에 꼭 필요한 값만 포함하기

가장 기본적인 원칙은 최소한의 정보만 반환하는 것입니다. 목록 화면에는 이름과 상태만 주고, 상세 화면에서만 일부 정보를 추가로 주는 식으로 분리할 수 있습니다. 이렇게 하면 API응답보안 측면에서 노출 범위를 줄이기 쉽습니다.

2) 마스킹과 분리된 엔드포인트 활용

전화번호, 이메일처럼 자주 쓰이지만 전부 공개할 필요는 없는 값은 일부만 마스킹해서 보여주는 방법이 있습니다. 또는 관리용과 사용자용 API를 분리해서 REST API별로 반환 범위를 다르게 설계하는 것도 도움이 됩니다. 이런 방식은 민감정보유출 위험을 낮추는 데 효과적입니다.

3) 로그와 디버깅 출력도 함께 점검하기

응답 본문을 직접 보여주지 않더라도 서버 로그, 에러 로그, 프론트엔드 콘솔 출력에 민감정보가 남는 경우가 있습니다. 결국 개인정보노출은 API 응답 하나만의 문제가 아니라 개발 흐름 전체의 문제로 보는 편이 맞습니다. 따라서 운영 전에는 로그 정책까지 같이 확인해야 합니다.

6. 간단한 점검만으로도 줄일 수 있는 위험

1) URL만 넣어 빠르게 기본 상태를 확인

복잡한 보안 진단 도구가 아니더라도, URL을 입력해 기본적인 보안 상태를 빠르게 살펴보는 방식이 도움이 될 수 있습니다. 예를 들어 HTTPS 적용 여부, 인증서 상태, 보안 헤더 같은 항목을 먼저 보면 기본적인 API응답보안 수준을 가늠하는 데 유용합니다.

2) 눈에 잘 안 띄는 노출 지점 찾기

.env, 소스코드, API 키처럼 직접적으로 드러나면 안 되는 정보는 생각보다 쉽게 놓칠 수 있습니다. 또한 브라우저에서 실제로 발생하는 XSS, Mixed Content 같은 문제도 함께 보면 민감정보유출로 이어질 수 있는 경로를 줄이는 데 도움이 됩니다. 이런 점에서 간단 점검 도구는 초기 확인용으로 적합한 편입니다.

3) 프로젝트 초기에 기준을 잡는 데 활용

한 번 기본 보안 기준을 정리해두면 이후 프로젝트에서도 같은 기준을 적용하기 쉬워집니다. REST API를 새로 만들 때마다 전화번호나 개인 정보가 응답에 들어가는지 반복해서 확인하는 습관이 생기기 때문입니다. 결국 개인정보노출을 줄이는 가장 현실적인 방법은 처음부터 기준을 통일해 두는 것입니다.

7. 이런 상황이라면 한 번 점검해볼 만합니다

1) 사용자 정보가 포함된 API를 자주 다룰 때

회원 정보, 주문 정보, 배송 정보처럼 개인정보가 포함된 API를 운영한다면 API응답보안을 정기적으로 확인하는 것이 좋습니다. 특히 REST API 응답에 전화번호나 이메일이 습관적으로 들어가는 구조라면 더욱 주의해야 합니다.

2) 개발은 빠르지만 보안 검토 시간이 부족할 때

실무에서는 기능 개발 일정이 우선되면서 세부 보안 점검이 뒤로 밀리는 경우가 많습니다. 이럴 때 최소한의 기준만 빠르게 확인해도 민감정보유출 가능성을 줄이는 데 도움이 됩니다. 개인정보노출은 큰 사고로 번지기 전에 기본 점검으로 발견하는 편이 훨씬 부담이 적습니다.

3) 직접 전화나 수동 확인보다 빠른 기준이 필요할 때

API 응답을 일일이 손으로 확인하려면 시간이 많이 들고, 사람마다 보는 기준도 달라질 수 있습니다. 반면 URL 기반 점검은 기본 설정과 노출 가능성을 빠르게 훑어볼 수 있어, 수동 전화처럼 매번 확인하는 방식보다 훨씬 일관적입니다. 물론 정밀한 보안 진단을 완전히 대체하는 것은 아니지만, API응답보안의 출발점으로는 충분히 유용한 편입니다.

결국 API응답보안은 거창한 보안 시스템보다, 응답에 어떤 정보가 포함되는지부터 차분히 확인하는 데서 시작합니다. 사용자 전화번호처럼 사소해 보이는 값도 잘못 내려가면 개인정보노출과 민감정보유출로 이어질 수 있기 때문입니다. 특히 REST API를 여러 화면에서 재사용하고 있다면 더더욱 응답 범위를 점검해볼 필요가 있습니다. 이런 상황에서는 URL만으로 기본 상태를 빠르게 확인하는 방식이 유용하고, 직접 전화하거나 일일이 수동으로 살피는 것보다 더 빠르게 이상 징후를 발견할 수 있습니다.