Top 12 this For API Security

요즘 대부분의 어플리케이션은 주로 API 를 통해 데이터를 처리하고 외부 시스템과의 통신을 중개하는 역할을 하는데요.


API  Security 를 신경쓰지 않으면 데이터 노출과 공격을 통해 비즈니스 운영에 심각한 차질을 불러올 수 있을거에요. 그래서 API Security 에 신경써야합니다.


다음은 ByteBytegGo 에서 알려주는 API Security 를 위한 12가지 팁입니다. 원문 링크도 첨부해둘게요~


1) Use HTTPS  

  • What

    • HTTPS는 HTTP에 SSL/TLS 보안 프로토콜을 적용한 것으로 데이터가 전송되는 동안 암호화되어 클라이언트와 서버 간에 안전하게 데이터를 전송할 수 있도록 해줍니다. 

    • 암호화는 데이터가 도난, 도청 (Eavesdropping), 변조 (Man-in-the-Middle, MiTM) 되는 것을 방지하며, 이는 사용자의 개인정보, 로그인 자격 증명 및 기타 민감한 정보를 안전하게 유지하는 역할을 합니다. 

  • When

    • API를 통해 데이터를 전송할 때는 항상 HTTPS 를 사용하는 것이 좋습니다. 

  • How

    • HTTPS를 구현하는 과정은 다음과 같습니다:

      • 1. SSL/TLS 인증서 획득: 도메인에 대한 SSL/TLS 인증서를 획득해야 합니다. 이 인증서는 공인된 인증 기관(CA)으로부터 구매하거나 Let’s Encrypt와 같은 서비스를 통해 무료로 발급받을 수 있습니다. 

      • 2. 서버 설정: 서버가 SSL/TLS 인증서를 사용하도록 설정해야 합니다. 이는 웹 서버 소프트웨어에 따라 다르지만, 일반적으로 인증서 파일을 서버에 설치하고, 서버 설정 파일에서 HTTPS를 활성화하는 과정을 포함합니다. 

      • 3. 리디렉션 구현: 모든 HTTP 요청을 HTTPS로 리디렉션하도록 서버를 설정합니다. 이렇게 하면 사용자가 HTTP를 통해 접근하려 할 때 자동으로 보안 연결로 전환됩니다.

      • 4. HSTS 설정: 웹 서버에서 HTTP Strict Transport Security(HSTS)를 활성화하여 브라우저가 해당 서버와의 통신을 오직 HTTPS를 통해서만 수행하도록 합니다. 이는 공격자가 사용자를 HTTP로 리디렉트 시키려는 시도를 차단하는 데 도움이 됩니다.

      • 5. API 클라이언트 업데이트: API 클라이언트가 HTTPS를 통해서만 데이터를 요청하도록 업데이트합니다. 이는 API를 사용하는 모든 애플리케이션에 적용되어야 합니다. 


2) Use OAuth 2.0: 

  • What

    • OAuth 2.0 은 애플리케이션 간의 안전한 권한 부여를 위해 널리 사용됩니다. 

    • OAuth 2.0은 클라이언트 애플리케이션이 사용자의 대리인으로서 리소스 서버에 접근할 수 있도록 토큰 기반 인증을 사용하는 권한 부여 프레임워크입니다. 사용자는 자신의 로그인 정보를 클라이언트에게 직접 제공하지 않고, 대신 OAuth 2.0 프로세스를 통해 클라이언트에게 엑세스 토큰을 발급합니다.

    • 클라이언트는 이 토큰을 통해서 리소스 서버에 제한된 접근을 해서 필요한 정보를 가져올 수 있습니다. 

  • When

    • 구글 로그인과 같은 기능을 만들고 싶을 때 

    • 사용자가 다른 서비스 (e.g 구글, 네이버, 카카오 등) 의 기능을 사용하려고 할 때

    • OAuth 2.0 은 구글과 같은 타사 서비스를 통한 로그인 기능 뿐 아니라 자체 서버 및 서비스 간의 인증과 권한 부여를 할 때도 매우 유용하니 자사의 마이크로서비스 아키텍처에서도 데이터를 공유하고 기능을 수행하는 경우에도 OAuth 2.0 을 사용하는 것이 유용할 수 있습니다. 

  • How

    • OAuth 2.0 구현의 핵심 단계는 다음과 같습니다:

    • 1. 클라이언트 등록: 애플리케이션을 OAuth 2.0을 제공하는 서비스에 클라이언트로 등록합니다. 이 과정에서 클라이언트 ID와 클라이언트 비밀번호가 발급되며, 리다이렉션 URI가 설정됩니다.

    • 2. 권한 요청: 사용자가 클라이언트 애플리케이션을 사용하여 로그인을 시도할 때, 애플리케이션은 사용자를 권한 서버의 로그인 페이지로 리다이렉션합니다.

    • 3. 사용자 인증 및 권한 부여: 사용자가 권한 서버에서 로그인하고 클라이언트 애플리케이션에 특정 권한을 부여합니다.

    • 4. 액세스 토큰 발급: 사용자가 권한을 부여하면, 권한 서버는 클라이언트 애플리케이션에 액세스 토큰을 발급합니다.

    • 5. 리소스 접근: 클라이언트는 발급받은 토큰을 사용하여 리소스 서버에 접근하고, 사용자 대신 작업을 수행할 수 있습니다.


3) WebAuthn: 

  • What

    • WebAuthn (Web Authentication)은 API 보안을 위한 최신 인증 표준입니다. 이 표준은 웹 기반 인증을 보다 강화하고 사용자 친화적으로 만드는 방법을 제공하는 방법입니다. 

    • 이는 사용자가 물리적인 보안 장치(예: 지문, 얼굴 인식, 보안 키 등)를 사용하여 웹사이트에 로그인할 수 있도록 지원합니다. 

    • 기존의 비밀번호 기반 인증 시스템의 보안 취약점을 해결하고, 보다 간편하고 안전한 인증 방법을 제공하려는 목적을 가지고 있습니다.

  • When

    • 사용자가 비밀번호를 기억하거나 입력할 필요 없이, 더 빠르고 안전하게 로그인하길 원할 때.

    • 기존의 인증 방법과 함께 추가 보안 계층을 제공하고자 할 때.

    • 피싱 및 기타 인증 공격을 방지하고자 할 때: (WebAuthn은 사용자 인증 정보의 도난을 방지하고, 인증 정보가 사용자의 물리적 장치에 저장되어 있기 때문에 외부에 노출되지 않습니다.)

  • How:

    • WebAuthn을 구현하는 단계는 다음과 같습니다: 

    • 1. 사용자는 자신의 물리적 장치(e.g YubiKey, 지문 스캐너 등)를 사용하여 웹사이트에 자신을 등록합니다. 이 과정에서 공개 키와 개인 키가 생성됩니다. 개인 키는 사용자의 장치에 안전하게 저장되며, 공개 키는 서버에 저장됩니다.

    • 2. 사용자가 웹사이트에 로그인할 때, 웹사이트는 사용자의 장치로 인증 요청을 보냅니다. 사용자의 장치는 사용자의 동의(지문 인식, PIN 입력 등)를 받아 개인 키를 사용하여 요청을 서명하고, 이 서명을 웹사이트로 전송합니다.

    • 3. 웹사이트 서버는 받은 서명을 사용자의 공개 키로 검증하여 인증을 완료합니다. 이 과정에서 사용자의 개인 정보는 전송되지 않으므로 보안이 유지됩니다.


4) Use Leveled API Keys 

  • What

    • API 키에 다양한 권한 수준을 부여하여 더 세밀하고 안전한 접근 제어를 가능하게 하는 방법입니다. 

    • Leveled API Keys는 API 사용자에게 부여되는 키로, 각 키는 설정된 권한 수준에 따라 API의 특정 부분에 대한 접근을 허용합니다. 이는 각 키가 일정한 권한 범위 내에서만 작동하도록 하여, 보안을 강화하고 불필요하거나 위험한 데이터 접근을 최소화합니다. 예를 들어, 일부 키는 읽기 전용 액세스를 허용하는 반면 다른 키는 데이터를 변경할 권한을 부여할 수 있습니다.

  • When

    • 데이터 노출 위험을 최소화할 때 (특정 사용자 또는 서비스가 필요로 하는 기능에만 접근할 수 있도록 하여 데이터 노출을 제한하고 싶을 때 유용합니다.) 

    • 다양한 사용자 또는 개발자 그룹에게 서로 다른 접근 권한을 부여해야 할 때.

    • API를 공개적으로 제공할 때 (공개 API를 제공하는 경우, 사용자별로 다른 권한 수준을 설정하여 보안을 강화할 수 있습니다.) 

  • How

    • Leveled API Keys를 구현하는 단계는 다음과 같습니다:

    • 1. 먼저, API에 대한 다양한 접근 권한 레벨을 정의합니다. 이는 읽기 전용, 쓰기 권한, 관리자 권한 등으로 나눌 수 있습니다.

    • 2. 각 키에 대해 특정 권한을 설정하고, 해당 키를 사용자 또는 애플리케이션에 할당합니다.

    • 3. API 서버에 접근 제어 로직을 구현하여, 각 요청이 적절한 키를 통해 이루어졌는지 확인하고, 해당 키가 허용하는 작업만 수행되도록 합니다.

    • 4. 모든 API 요청을 모니터링하고 로깅하여, 비정상적인 접근 시도나 권한 남용을 감지할 수 있도록 합니다.

    • 그리고 Leveled API Keys를 사용할 때는 키가 노출되지 않도록 주의해야 하며, 정기적으로 키를 갱신하거나 만료시키는 것이 좋습니다.


5) Implement Authorization (RBAC)

  • What

    • RBAC는 사용자의 역할에 따라 시스템 자원에 대한 접근 권한을 관리하는 방식으로, 사용자를 특정 역할에 할당하고 각 역할에 필요한 권한을 부여하는 방법입니다. 

    • 각 역할은 특정 권한을 가지고 있으며, 사용자는 해당 역할에 따라 시스템의 자원을 사용할 수 있는 권한을 부여받습니다. 예를 들어, "관리자" 역할은 시스템 설정 변경 권한을 가질 수 있으며, "사용자" 역할은 정보 조회 권한만을 가질 수 있습니다.

  • When

    • 많은 수의 사용자와 다양한 접근 요구 사항을 관리해야 할 때

    • 데이터의 보안을 강화하고, 불필요한 접근으로부터 보호해야 할 때 

  • How

    • RBAC을 구현하는 단계는 다음과 같습니다:

    • 1. 시스템에서 필요로 하는 모든 역할을 식별하고 정의합니다. 각 역할은 특정 권한 집합과 연결됩니다.

    • 2. 각 사용자를 적절한 역할에 할당합니다. 사용자는 할당된 역할에 따라 권한을 부여받게 됩니다. 

    • 3. 각 역할에 필요한 권한을 정확히 설정합니다. 이는 데이터베이스, 파일 시스템, 네트워크 자원 등에 대한 접근을 포함할 수 있습니다.

    • 4. 시스템은 사용자의 요청이 들어올 때마다 해당 사용자의 역할을 검증하고, 해당 역할에 부여된 권한에 따라 요청을 승인하거나 거부합니다.

    • 5. RBAC 시스템은 사용자의 행위와 권한 변경 사항을 기록하여, 보안 감사 및 규정 준수를 지원합니다.


6) Rate Limiting

  • What

    • Rate Limiting은 사용자 또는 서비스가 일정 시간 동안 API를 호출할 수 있는 횟수를 제한하는 기술입니다. 이 기법은 서버에 과도한 부하가 걸리는 것을 방지하고, DDoS 공격 같은 악의적인 행위를 차단하기 위해 사용됩니다.

    • Rate Limiting을 적용하면, 각 사용자 ID, IP Address 또는 API Key 별로 요청 허용 횟수를 설정하고, 초과하는 요청은 자동으로 거부하게 됩니다. 

  • When

    • 시스템이 갑작스러운 트래픽 증가를 겪을 때, 예를 들어 프로모션 기간이나 중요 이벤트 동안.

    • API를 대상으로 한 DDoS 공격이나 크롤링 등의 악의적인 사용을 막을 때.

    • 모든 사용자가 서비스를 공정하게 이용할 수 있도록 하기 위해.

  • How

    • Rate Limiting을 구현하는 단계는 다음과 같습니다:

    • 1. API 사용 정책을 바탕으로 적절한 Rate Limit 값을 설정합니다. 이 값은 요청의 수, 시간 단위(예: 분, 시간, 일) 및 대상 사용자 또는 IP를 고려하여 결정됩니다.

    • 2. Rate Limiting을 구현하기 위해, 많은 API 게이트웨이 또는 웹 프레임워크에서 지원하는 기능을 활용할 수 있습니다. 예를 들어, Nginx, AWS API Gateway, Kong 등이 있습니다.

    • 3. Rate Limit을 초과하는 요청에 대해 사용자에게 적절한 오류 메시지(예: HTTP 429 Too Many Requests)를 반환하여 통지합니다.

    • 4. Rate Limiting 정책은 시간에 따라 변할 수 있으므로, 지속적인 모니터링과 필요에 따라 조정이 중요합니다.

    • Rate Limiting을 적용할 때는 너무 엄격하게 제한하면 정상적인 사용자 경험을 저해할 수 있으므로, 사용자의 요구와 서버의 용량을 적절히 고려해야 합니다. 또한, 다양한 사용자나 시스템의 요구를 반영하여 접근하는 리소스의 종류에 따라 여러 레벨의 Rate Limit 을 설정할 수도 있습니다.


7) API Versioning 

  • What

    • API의 여러 버전을 관리하고 유지하는 전략으로, 기존의 사용자와 시스템이 새로운 변경 사항으로 인해 영향을 받지 않도록 즉 하위 호환성을 보장합니다. 

    • 이를 통해 개발자는 API의 새로운 기능을 추가하거나 변경할 수 있으며, 이전 버전의 API를 계속 사용하려는 사용자에게 영향을 주지 않습니다. 버전 관리는 URL 경로, 헤더, 또는 쿼리 매개변수를 통해 수행될 수 있습니다.

  • When

    • API 에 새로운 기능을 추가하거나 기존 기능을 수정할 때, 기존 사용자에게 영향을 주지 않기 위해 새 버전을 생성할 수 있습니다. 

    • 이전 버전의 API를 사용하는 기존 클라이언트와의 호환성을 유지하면서 서비스를 개선하고 싶을 때.

    • 장기적인 미래의 확장성과 유연성을 고려하여 API를 설계할 때.

  • How

    • API Versioning을 구현하는 방법은 여러 가지가 있습니다:

    • 1. URL Versioning: URL 경로에 버전 번호를 포함시켜 다른 버전의 API를 호출할 수 있게 합니다. 예: https://api.example.com/v1/resource

    • 2. Header Versioning: HTTP 헤더를 사용하여 버전 정보를 전달합니다. 클라이언트는 특정 버전을 요청할 때 HTTP 헤더에 버전 정보를 포함시켜 요청을 보냅니다.

    • 3. Query String Versioning: 요청의 쿼리 매개변수를 통해 버전 정보를 전달합니다. 예: https://api.example.com/resource?version=1

    • API Versioning 을 이용할 땐 각 버전의 API는 명확하게 문서화되어야 합니다. 그리고 오래된 버전의 API 는 언제 어떻게 단계적으로 제거할지에 대한 명확한 정책을 수립하는 것이 좋습니다. 


8) AllowListing 

  • What

    • 이는 특정 사용자, IP Address 또는 API Key 만을 사전에 승인된 목록에 등록하여 해당 소스로부터의 요청만을 허용하는 방식입니다. 그래서 “Deny all, Permit some” 방식이라고도 합니다. 

    • 이 방식을 통해 특정 네트워크, 사용자 또는 서비스만이 API에 접근할 수 있도록 제한하여 보안을 강화할 수 있습니다. 

  • When

    • 중요한 데이터를 다루는 API나, 외부로부터의 접근을 엄격히 제한해야 할 때.

    • 기업 내부 네트워크나 제한된 네트워크에서만 작동해야 하는 서비스의 경우.

    • 의료 등 규제가 많은 산업에서는 데이터 접근을 엄격하게 통제하기 위해서 이 방법을 사용할 수 있습니다. 

  • How

    • Allowlisting을 구현하는 방법은 다음과 같습니다:

    • 1. 승인된 IP 주소, 사용자 ID, 디바이스 ID 등의 목록을 생성합니다. 이 목록은 API 보안 게이트웨이 또는 서버 설정에 포함될 수 있습니다.

    • 2. API 접근을 허용할 기준을 설정하고, 이 기준에 맞지 않는 요청은 차단합니다. 

    • 3. 보안 게이트웨이나 방화벽을 사용하여 허용된 요청만이 API 서버로 전달되도록 합니다.

    • 4. 보안 상황이 변경될 때마다 allowlist를 검토하고 필요에 따라 업데이트합니다.

    • AllowListing 은 효과적인 보안 수단이지만, 유연성을 제한할 수 있으므로 너무 엄격하게 적용할 경우 정상적인 사용자의 활동을 방해할 수 있다는 점을 알고 적용해야합니다. 


9) Check OWASP API Security Risks

  • What

    • OWASP (Open Web Application Security Project)는 웹 애플리케이션과 API 보안에 대한 연구, 문서화 및 도구를 제공하는 비영리 국제 기구입니다. 

    • 이들이 제공하는 API 보안 위험 목록은 개발자와 보안 전문가들이 API를 설계하고 구현할 때 고려해야 할 주요 보안 위험을 정의하므로 따르는 것이 좋습니다. 

    • 대표적인 OWASP API Security Top 10 목록은 다음과 같습니다: 

      • Broken Object Level Authorization (BOLA): 객체 수준 권한 검증이 잘못되어 사용자가 권한이 없는 데이터에 접근할 수 있게 되는 취약점입니다.

      • Broken User Authentication: 인증 메커니즘이 취약하여, 공격자가 사용자의 계정을 도용하거나 세션 토큰을 조작하는 등의 행위를 통해 인증된 사용자처럼 행동할 수 있는 취약점입니다.

      • Excessive Data Exposure: 개발자가 클라이언트 측에서 데이터를 필터링하도록 의도하거나 구현하지 않아, 민감한 데이터가 노출되는 취약점입니다

      • Lack of Resources & Rate Limiting: API가 적절한 자원 할당 또는 요청률 제한을 구현하지 않아, 서비스 거부(DoS) 공격에 취약해지는 경우입니다.

      • Broken Function Level Authorization: 함수 수준에서의 권한 부여가 잘못되어, 사용자가 권한이 없어야 할 API 기능을 사용할 수 있게 되는 취약점입니다

      • Mass Assignment: 클라이언트가 보내는 데이터를 제대로 필터링하지 않아, 공격자가 의도치 않은 방식으로 데이터 객체의 속성을 변경할 수 있는 취약점입니다

      • Security Misconfiguration: 보안 구성이 잘못되어 기본 설정, 불완전한 또는 잘못된 구성,불필요하게 활성화된 기능 등으로 인해 발생하는 취약점입니다

      • Injection: SQL, NoSQL, LDAP 주입 등 사용자의 데이터가 API에 전달될 때 적절한 처리가 이루어지지 않아, 공격자가 악의적인 코드를 주입할 수 있는 취약점입니다

      • Improper Assets Management: API 버전 관리와 호스팅이 적절히 이루어지지 않아, 구버전 API나 미사용 API가 공격 대상이 되는 경우입니다

      • Insufficient Logging & Monitoring: 로깅과 모니터링이 부족하여 보안 침해 사고를 식별하고 대응하는 데 필요한 시간이 지연되거나, 침해 사실을 인지하지 못하는 취약점입니다.

  • When

    • API 설계 초기 단계에서 미리 적용하는 것이 좋습니다. 

    • 위험 요소가 추가될 때마다 대응하는 것이 좋습니다. 

  • How

    • 1. OWASP 웹사이트나 관련 문서에서 최신 API 보안 위험 목록을 참조합니다.

    • 2. 개발 중이거나 이미 구현된 API를 대상으로 각 위험 요소를 평가하여 취약점을 분석합니다.

    • 3. 각 위험 요소에 대해 특정 완화 전략을 수립하고 적용합니다. 이에는 코딩 가이드라인, 보안 설정, 제3자 보안 도구의 사용 등이 포함될 수 있습니다.


10) Use API Gateway 

  • What:

    • API Gateway는 클라이언트와 서비스 간의 인터페이스 역할을 하는 서버입니다. 이는 모든 인바운드 API 요청을 수신하고, 이 요청들을 적절한 내부 서비스로 라우팅하는 역할을 합니다. 또한, API Gateway는 Authentication, Rate Limiting, Caching, Logging, Monitoring 같은 중요한 기능을 통합하여 API의 성능과 보안을 향상시킵니다. 

  • When

    • 서비스가 여러 작은 마이크로서비스로 분할되어 있을 때, 각 서비스 간의 통신을 조율하고 관리하는 데 API Gateway 를 사용할 수 있습니다. 

    • API에 대한 보안 강화가 필요할 때 API Gateway 에서 인증 및 인가, API 키 검증 등의 보안 기능을 통해 비인가 접근을 차단할 수 있습니다. 

    • 트래픽이 많은 API를 운영할 때 API Gateway 를 통해 요청의 속도 제한이나 캐싱을 통해 서버 부하를 줄이고 성능을 개선할 수 있습니다. 

    • API Gateway 를 이용해서 API 사용 패턴을 모니터링하고 로깅하여, 보안 위협을 식별하고 성능 문제를 해결할 수 있습니다. 

  • How

    • 1. API Gateway 소프트웨어를 선택하고 설치한 후, 특정 네트워크 환경에 맞게 구성합니다.

    • 2. 클라이언트 요청을 적절한 백엔드 서비스로 라우팅하기 위한 규칙을 정의합니다.

    • 3. 인증, 인가, API 키 관리, SSL/TLS 등의 보안 메커니즘을 설정합니다.

    • 4. 서비스의 성능을 유지하고 과도한 트래픽에 대응하기 위해 요청 속도 제한 및 캐싱 규칙을 구현합니다.

    • 5. API 사용 상황을 모니터링하고 로그를 수집하여 보안과 성능을 지속적으로 모니터링합니다.


11) Error Handling 

  • What

    • Error Handling은 API에서 발생하는 다양한 오류 조건을 식별하고, 이에 대한 적절한 응답을 생성하는 프로세스입니다. 이는 클라이언트가 API 요청을 보내면서 발생한 문제에 대해 적절한 안내를 받을 수 있도록 해줍니다.

    • 단순히 "Internal Server Error" 라고 모호한 메시지를 보내는 것보다 "Failed to retrieve users data. Please check that your are authenticated and have sufficient permissions" 라고 응답주는 것이 문제 해결에 더 도움을 주는 메시지일 겁니다. 

  • When:

    • 사용자가 부정확한 요청을 보내거나, 서버 측의 문제로 인해 예기치 않은 오류가 발생할 때.

    • 사용자가 오류를 이해하고 문제를 해결할 수 있도록 명확하고 유용한 오류 메시지를 제공하기 위해 사용할 수 있습니다.

  • How

    • 1. API에서 예외를 적절하게 처리하고, 클라이언트에게 적절한 오류/상태 코드와 함께 응답을 반환하도록 합니다. 

    • 2. 클라이언트가 오류를 이해하고 문제를 해결할 수 있도록 명확하고 유용한 오류 메시지를 제공하도록 합니다. 

    • 3. 오류 메시지가 클라이언트에게 민감한 정보를 노출하지 않도록 제어하고, 보안 취약점을 최소화 하도록 합니다. (예로, 스택 트레이스 같은 정보는 노출하지 않는 것이 좋습니다.) 

    • 4. 발생한 오류를 기록하고 모니터링하여 시스템의 문제를 파악하고 해결할 수 있도록 구성하도록 합니다. 

    • 5. 적절한 HTTP 상태 코드를 사용하여 클라이언트에게 오류 유형을 알려줘야 합니다. 


12) Input Validation 

  • What

    • Input Validation은 클라이언트로부터 수신한 입력 데이터의 유효성을 확인하는 과정입니다. 이는 입력 데이터가 기대한 형식과 구조에 부합하는지 확인하여, 악의적인 사용자로부터의 공격을 방어하고 시스템의 안정성을 유지할 수 있습니다.

  • When

    • 사용자가 제공한 입력 데이터를 처리할 때, 데이터의 유효성을 검증하여 악의적인 데이터를 거부할 수 있습니다. 

  • How

    • 1. 일반적인 입력 유효성 검사를 위한 라이브러리를 사용하여, 입력 데이터의 형식과 구조를 확인할 수 있습니다. 

    • 2. 정규 표현식을 사용하여 입력 데이터의 패턴을 확인하고, 유효성을 검증할 수 있습니다. 

    • 3. 특수 문자나 SQL 삽입 등의 공격을 방어하기 위해, 입력 데이터에 허용되지 않는 문자나 문자열을 거부할 수 있습니다. 

    • 4. 입력 데이터의 길이를 제한하여, 과도한 데이터 양으로 인한 시스템 부하를 방지하고 데이터 무결성을 유지할 수 있습니다. 

    • 5. 입력 데이터의 유형을 명시적으로 캐스팅하여, 의도하지 않은 형변환에 의한 보안 취약점을 방어할 수 있습니다.


https://www.youtube.com/watch?v=6WZ6S-qmtqY

Top 12 Tips For API Security

YouTube

Top 12 Tips For API Security

다음 내용이 궁금하다면?

또는

이미 회원이신가요?

2024년 5월 6일 오전 8:26

 • 

저장 188조회 4,970

댓글 0