보안 코딩 관행

OWASP 보안 코딩 사례 - 빠른 참조 가이드

보안 코딩 관행

보안 코딩 관행 체크리스트

입력 유효성 검사

• 신뢰할 수 있는 시스템에서 모든 입력 유효성 검사 수행(클라이언트 측이 아닌 서버 측)
• 모든 데이터 소스를 식별하고 신뢰할 수 있는 것과 신뢰할 수 없는 것으로 분류
• 신뢰할 수 없는 소스(데이터베이스, 파일 스트림 등)의 모든 데이터 유효성 검사
• 전체 애플리케이션에 대해 중앙 집중식 입력 유효성 검사 루틴 사용
• 모든 입력 소스에 대해 UTF-8과 같은 문자 세트 지정(표준화)
• 유효성을 검사하기 전에 공통 문자 집합으로 입력을 인코딩합니다.
• 모든 유효성 검사 실패는 입력 거부로 이어져야 합니다.
• 시스템이 UTF-8 확장 문자 집합을 지원하고 UTF-8 디코딩이 완료된 후 확인하는 경우
• 처리하기 전에 클라이언트가 제공한 모든 데이터의 유효성을 검사합니다.
• 요청 및 응답의 프로토콜 헤더 값에 ASCII 문자만 포함되어 있는지 확인하십시오.
• 리디렉션에서 데이터 유효성 검사
• "거부" 목록이 아닌 "허용" 목록을 사용하여 예상 데이터 유형에 대한 유효성 검사
• 데이터 범위 확인
• 데이터 길이 확인
• 잠재적으로 위험한 입력을 허용해야 하는 경우 추가 제어를 구현합니다.
• 표준 유효성 검사 루틴이 일부 입력을 처리할 수 없는 경우 추가 개별 검사를 사용합니다.
• 난독화 공격을 해결하기 위해 정규화 활용

출력 인코딩

• 신뢰할 수 있는 시스템에서 모든 출력 인코딩 수행(클라이언트 측이 아닌 서버 측)
• 아웃바운드 인코딩의 각 유형에 대해 테스트된 표준 루틴을 활용합니다.
• 모든 출력에 대해 UTF-8과 같은 문자 집합을 지정합니다.
• 신뢰할 수 없는 소스에서 클라이언트로 반환된 모든 데이터를 컨텍스트 출력 인코딩
• 출력 인코딩이 모든 대상 시스템에 대해 안전한지 확인합니다.
• SQL, XML 및 LDAP에 대한 쿼리에 대한 신뢰할 수 없는 데이터의 모든 출력을 상황에 맞게 삭제합니다.
• 신뢰할 수 없는 데이터의 모든 출력을 운영 체제 명령으로 삭제

인증 및 비밀번호 관리

• 특별히 공개하려는 페이지를 제외한 모든 페이지와 리소스에 대해 인증을 요구합니다.
• 모든 인증 제어는 신뢰할 수 있는 시스템에서 시행되어야 합니다.
• 가능할 때마다 표준, 테스트, 인증 서비스를 설정하고 활용하십시오.
• 외부 인증 서비스를 호출하는 라이브러리를 포함하여 모든 인증 제어에 중앙 집중식 구현 사용
• 요청 중인 리소스에서 인증 논리를 분리하고 중앙 집중식 인증 제어와의 리디렉션 사용
• 모든 인증 제어는 안전하게 실패해야 합니다.
• 모든 관리 및 계정 관리 기능은 적어도 기본 인증 메커니즘만큼 안전해야 합니다.
• 애플리케이션이 자격 증명 저장소를 관리하는 경우 암호학적으로 강력한 단방향 소금 해시를 사용하십시오.
• 암호 해싱은 클라이언트 측이 아닌 신뢰할 수 있는 시스템 서버 측에서 구현해야 함)
• 모든 데이터 입력이 완료된 경우에만 인증 데이터 유효성 검사
• 인증 실패 응답은 인증 데이터의 어느 부분이 잘못되었는지 나타내면 안 됩니다.
• 민감한 정보나 기능이 포함된 외부 시스템에 대한 연결에 인증 활용
• 애플리케이션 외부 서비스에 액세스하기 위한 인증 자격 증명은 안전한 저장소에 저장해야 합니다.
• HTTP POST 요청만 사용하여 인증 자격 증명 전송
• 암호화된 연결을 통해 또는 암호화된 데이터로만 비임시 비밀번호를 전송합니다.
• 정책 또는 규정에 의해 설정된 암호 복잡성 요구 사항을 시행합니다.
• 정책 또는 규정에 의해 설정된 암호 길이 요구 사항 시행
• 비밀번호 입력은 사용자 화면에서 가려져야 합니다.
• 유효하지 않은 로그인 시도 횟수가 설정된 후 계정 비활성화 시행
• 암호 재설정 및 변경 작업에는 계정 생성 및 인증과 동일한 수준의 제어가 필요합니다.
• 암호 재설정 질문은 임의 답변을 충분히 지원해야 합니다.
• 이메일 기반 재설정을 사용하는 경우 임시 링크/비밀번호가 있는 사전 등록된 주소로만 이메일을 보내십시오.
• 임시 비밀번호와 링크는 만료 시간이 짧아야 합니다.
• 다음 사용 시 임시 비밀번호 변경을 시행합니다.
• 암호 재설정이 발생하면 사용자에게 알림
• 비밀번호 재사용 방지
• 비밀번호 재사용에 대한 공격을 방지하려면 비밀번호를 변경하기 전에 최소 1일이 지난 비밀번호여야 합니다.
• 정책 또는 규정에 설정된 요구 사항에 따라 암호 변경을 시행하고 재설정 사이의 시간은 관리자가 제어합니다.
• 암호 필드에 대한 "기억하기" 기능 비활성화
• 사용자 계정의 마지막 사용(성공 또는 실패)은 다음에 성공적으로 로그인할 때 사용자에게 보고되어야 합니다.
• 동일한 암호를 사용하여 여러 사용자 계정에 대한 공격을 식별하기 위한 모니터링 구현
• 공급업체에서 제공한 모든 기본 암호 및 사용자 ID를 변경하거나 관련 계정을 비활성화합니다.
• 중요한 작업을 수행하기 전에 사용자를 재인증합니다.
• 매우 민감하거나 가치가 높은 트랜잭션 계정에 Multi-Factor Authentication 사용
• 인증을 위해 타사 코드를 사용하는 경우 코드를 주의 깊게 검사하여 악성 코드의 영향을 받지 않도록 합니다.

세션 관리

• 서버 또는 프레임워크의 세션 관리 컨트롤을 사용합니다. 애플리케이션은 이러한 세션 식별자만 유효한 것으로 인식해야 합니다.
• 세션 식별자 생성은 항상 신뢰할 수 있는 시스템에서 수행되어야 합니다(클라이언트 측이 아닌 서버 측).
• 세션 관리 컨트롤은 충분히 무작위적인 세션 식별자를 보장하는 검증된 알고리즘을 사용해야 합니다.
• 인증된 세션 식별자를 포함하는 쿠키의 도메인 및 경로를 사이트에 대해 적절하게 제한된 값으로 설정합니다.
• 로그아웃 기능은 연결된 세션 또는 연결을 완전히 종료해야 합니다.
• 인증으로 보호되는 모든 페이지에서 로그아웃 기능을 사용할 수 있어야 합니다.
• 위험과 비즈니스 기능 요구 사항의 균형을 기준으로 가능한 한 짧은 세션 비활성 제한 시간을 설정합니다.
• 영구 로그인을 허용하지 않고 세션이 활성 상태인 경우에도 주기적인 세션 종료를 적용합니다.
• 로그인 전에 세션이 설정되었으면 해당 세션을 닫고 로그인 성공 후 새 세션을 설정합니다.
• 모든 재인증 시 새 세션 식별자 생성
• 동일한 사용자 ID로 동시 로그인 허용하지 않음
• URL, 오류 메시지 또는 로그에 세션 식별자를 노출하지 마십시오.
• 서버의 다른 사용자의 무단 액세스로부터 서버 측 세션 데이터를 보호하기 위해 적절한 액세스 제어 구현
• 새 세션 식별자를 생성하고 이전 식별자를 주기적으로 비활성화합니다.
• 인증 중에 발생할 수 있는 것처럼 연결 보안이 HTTP에서 HTTPS로 변경되는 경우 새 세션 식별자를 생성합니다.
• HTTP에서 HTTPS로 전환하는 대신 지속적으로 HTTPS를 활용합니다.
• 세션별 ​​강력한 랜덤 토큰 또는 매개변수를 활용하여 계정 관리와 같은 민감한 서버 측 작업에 대한 표준 세션 관리를 보완합니다.
• 세션별이 아닌 요청별, 강력한 랜덤 토큰 또는 매개변수를 활용하여 매우 민감하거나 중요한 작업에 대한 표준 세션 관리를 보완합니다.
• TLS 연결을 통해 전송되는 쿠키의 "보안" 속성 설정
• 쿠키 값을 읽거나 설정하기 위해 응용 프로그램 내에서 클라이언트 측 스크립트가 특별히 필요하지 않은 경우 HttpOnly 특성으로 쿠키를 설정합니다.

액세스 제어

• 액세스 권한 결정을 위해 신뢰할 수 있는 시스템 개체(예: 서버측 세션 개체)만 사용
• 단일 사이트 전체 구성 요소를 사용하여 액세스 권한을 확인하십시오. 여기에는 외부 인증 서비스를 호출하는 라이브러리가 포함됩니다.
• 액세스 제어는 안전하게 실패해야 합니다.
• 애플리케이션이 보안 구성 정보에 액세스할 수 없는 경우 모든 액세스 거부
• 서버 측 스크립트에 의한 요청을 포함하여 모든 요청에 ​​대해 권한 부여 제어를 시행합니다.
• 다른 애플리케이션 코드에서 특권 논리 분리
• 애플리케이션의 직접 통제 범위 밖에 있는 파일이나 기타 리소스에 대한 액세스를 권한이 있는 사용자로만 제한합니다.
• 보호된 URL에 대한 액세스를 인증된 사용자로만 제한
• 인증된 사용자만 보호된 기능에 액세스하도록 제한
• 인증된 사용자에게만 직접 개체 참조를 제한합니다.
• 인증된 사용자만 서비스에 액세스하도록 제한
• 승인된 사용자만 애플리케이션 데이터에 액세스하도록 제한
• 액세스 제어에서 사용하는 사용자 및 데이터 속성과 정책 정보에 대한 액세스 제한
• 보안 관련 구성 정보에 대한 액세스를 인증된 사용자로 제한
• 액세스 제어 규칙의 서버측 구현 및 프레젠테이션 계층 표현이 일치해야 합니다.
• 상태 데이터를 클라이언트에 저장해야 하는 경우 서버 측에서 암호화 및 무결성 검사를 사용하여 상태 변조를 감지합니다.
• 비즈니스 규칙을 준수하도록 애플리케이션 논리 흐름 적용
• 단일 사용자 또는 장치가 주어진 시간 동안 수행할 수 있는 트랜잭션 수를 자동화된 공격을 방지할 수 있을 만큼 낮지만 실제 비즈니스 요구 사항보다 높게 제한합니다.
• "referer" 헤더를 추가 확인으로만 사용하십시오. 스푸핑될 수 있으므로 유일한 인증 확인이 되어서는 안 됩니다.
• 긴 인증 세션이 허용되는 경우 사용자의 권한이 변경되지 않았는지 주기적으로 재확인하여 권한이 변경되지 않았는지 확인하고 변경된 경우 사용자를 로그아웃하고 강제로 재인증하도록 합니다.
• 계정 감사 구현 및 미사용 계정 비활성화 시행
• 애플리케이션은 승인이 중단될 때 계정 비활성화 및 세션 종료를 지원해야 합니다.
• 서비스 계정 또는 외부 시스템과의 연결을 지원하는 계정은 가능한 최소한의 권한을 가져야 합니다.
• 액세스를 적절하게 프로비저닝하고 제어할 수 있도록 애플리케이션의 비즈니스 규칙, 데이터 유형 및 액세스 권한 부여 기준 및/또는 프로세스를 문서화하는 액세스 제어 정책을 만듭니다. 여기에는 데이터 및 시스템 리소스 모두에 대한 액세스 요구 사항 식별이 포함됩니다.

암호화 관행

• 애플리케이션 사용자로부터 비밀을 보호하는 데 사용되는 모든 암호화 기능은 신뢰할 수 있는 시스템에서 구현되어야 합니다.
• 무단 액세스로부터 비밀 보호
• 암호화 모듈은 안전하게 실패해야 합니다.
• 모든 난수, 난수 파일 이름, 난수 GUID 및 난수 문자열은 암호화 모듈의 승인 난수 생성기를 사용하여 생성해야 합니다.
• 애플리케이션에서 사용하는 암호화 모듈은 FIPS 140-2 또는 동등한 표준을 준수해야 합니다.
• 암호화 키 관리 방법에 대한 정책 및 프로세스 수립 및 활용

오류 처리 및 로깅

• 시스템 세부 정보, 세션 식별자 또는 계정 정보를 포함하여 오류 응답에 민감한 정보를 공개하지 마십시오.
• 디버깅 또는 스택 추적 정보를 표시하지 않는 오류 핸들러 사용
• 일반 오류 메시지 구현 및 사용자 지정 오류 페이지 사용
• 애플리케이션은 애플리케이션 오류를 처리하고 서버 구성에 의존하지 않아야 합니다.
• 오류 조건이 발생할 때 적절하게 할당된 메모리를 해제합니다.
• 보안 제어와 관련된 오류 처리 논리는 기본적으로 액세스를 거부해야 합니다.
• 모든 로깅 제어는 신뢰할 수 있는 시스템에서 구현되어야 합니다.
• 로깅 컨트롤은 지정된 보안 이벤트의 성공과 실패를 모두 지원해야 합니다.
• 로그에 중요한 로그 이벤트 데이터가 포함되어 있는지 확인
• 신뢰할 수 없는 데이터가 포함된 로그 항목이 의도한 로그 보기 인터페이스 또는 소프트웨어에서 코드로 실행되지 않도록 합니다.
• 승인된 개인만 로그에 액세스하도록 제한
• 모든 로깅 작업에 중앙 루틴 활용
• 불필요한 시스템 세부 정보, 세션 식별자 또는 암호를 포함하여 민감한 정보를 로그에 저장하지 마십시오.
• 로그 분석을 수행하기 위한 메커니즘이 존재하는지 확인
• 모든 입력 유효성 검사 실패 기록
• 모든 인증 시도, 특히 실패 기록
• 모든 액세스 제어 실패 기록
• 상태 데이터에 대한 예기치 않은 변경을 포함하여 명백한 변조 이벤트를 모두 기록합니다.
• 유효하지 않거나 만료된 세션 토큰과의 연결 시도 기록
• 모든 시스템 예외 기록
• 보안 구성 설정에 대한 변경 사항을 포함하여 모든 관리 기능을 기록합니다.
• 모든 백엔드 TLS 연결 실패 기록
• 암호화 모듈 오류 기록
• 암호화 해시 함수를 사용하여 로그 항목 무결성 검증

데이터 보호

• 최소 권한을 구현하고 작업을 수행하는 데 필요한 기능, 데이터 및 시스템 정보로만 사용자를 제한합니다.
• 무단 액세스로부터 서버에 저장된 중요한 데이터의 모든 캐시 또는 임시 복사본을 보호하고 더 이상 필요하지 않은 임시 작업 파일을 즉시 제거하십시오.
• 서버 측에서도 인증 확인 데이터와 같은 매우 민감한 저장 정보를 암호화하십시오.
• 사용자가 서버 측 소스 코드를 다운로드하지 못하도록 보호
• 암호, 연결 문자열 또는 기타 중요한 정보를 일반 텍스트 또는 클라이언트 측의 암호화되지 않은 보안 방식으로 저장하지 마십시오.
• 백엔드 시스템 또는 기타 민감한 정보를 노출할 수 있는 사용자 액세스 가능한 프로덕션 코드에서 주석 제거
• 불필요한 응용 프로그램 및 시스템 문서를 제거하면 공격자에게 유용한 정보가 노출될 수 있습니다.
• HTTP GET 요청 매개변수에 민감한 정보를 포함하지 마십시오.
• 인증을 포함하여 민감한 정보가 포함될 것으로 예상되는 양식에서 자동 완성 기능 비활성화
• 민감한 정보가 포함된 페이지에서 클라이언트 측 캐싱 비활성화
• 해당 데이터가 더 이상 필요하지 않은 경우 응용 프로그램은 민감한 데이터 제거를 지원해야 합니다.
• 서버에 저장된 중요한 데이터에 대해 적절한 액세스 제어를 구현합니다. 여기에는 캐시된 데이터, 임시 파일 및 특정 시스템 사용자만 액세스할 수 있는 데이터가 포함됩니다.

통신 보안

• 모든 민감한 정보의 전송을 위한 암호화를 구현하십시오. 여기에는 연결을 보호하기 위한 TLS가 포함되어야 하며 중요한 파일 또는 HTTP 기반이 아닌 연결의 개별 암호화로 보완될 수 있습니다.
• TLS 인증서는 유효하고 올바른 도메인 이름을 가지고 있어야 하며 만료되지 않아야 하며 필요할 때 중간 인증서와 함께 설치되어야 합니다.
• 실패한 TLS 연결은 안전하지 않은 연결로 대체되어서는 안 됩니다.
• 인증된 액세스가 필요한 모든 콘텐츠 및 기타 모든 민감한 정보에 대해 TLS 연결을 활용합니다.
• 민감한 정보 또는 기능이 포함된 외부 시스템에 대한 연결에 TLS 활용
• 적절하게 구성된 단일 표준 TLS 구현 활용
• 모든 연결에 대한 문자 인코딩 지정
• 외부 사이트에 연결할 때 HTTP 리퍼러의 민감한 정보를 포함하는 필터 매개변수

시스템 설정

• 서버, 프레임워크 및 시스템 구성 요소가 최신 승인 버전을 실행하는지 확인
• 서버, 프레임워크 및 시스템 구성 요소에 사용 중인 버전에 대해 모든 패치가 발행되었는지 확인
• 디렉토리 목록 끄기
• 웹 서버, 프로세스 및 서비스 계정을 가능한 최소한의 권한으로 제한
• 예외 발생 시 안전하게 실패
• 불필요한 기능 및 파일 모두 제거
• 배포하기 전에 프로덕션용이 아닌 테스트 코드 또는 기능을 제거하십시오.
• 공개 색인 생성용이 아닌 디렉토리를 격리된 상위 디렉토리에 배치하여 robots.txt 파일의 디렉토리 구조 공개를 방지합니다.
• 응용 프로그램에서 지원하는 HTTP 메서드(Get 또는 Post)와 응용 프로그램의 다른 페이지에서 다르게 처리할지 여부를 정의합니다.
• 불필요한 HTTP 메서드 비활성화
• 웹 서버가 다른 버전의 HTTP를 처리하는 경우 유사한 방식으로 구성되고 차이점이 이해되는지 확인하십시오.
• OS, 웹 서버 버전 및 애플리케이션 프레임워크와 관련된 HTTP 응답 헤더에서 불필요한 정보 제거
• 애플리케이션의 보안 구성 저장소는 감사를 지원하기 위해 사람이 읽을 수 있는 형식으로 출력될 수 있어야 합니다.
• 자산 관리 시스템 구현 및 시스템 구성 요소 및 소프트웨어 등록
• 프로덕션 네트워크에서 개발 환경을 격리하고 승인된 개발 및 테스트 그룹에만 액세스를 제공합니다.
• 소프트웨어 변경 제어 시스템을 구현하여 개발 및 프로덕션 모두에서 코드 변경 사항을 관리하고 기록합니다.

데이터베이스 보안

• 강력한 형식의 매개 변수가 있는 쿼리 사용
• 입력 유효성 검사 및 출력 인코딩을 활용하고 메타 문자를 처리해야 합니다. 실패하면 데이터베이스 명령을 실행하지 마십시오.
• 변수가 강력한 형식인지 확인
• 응용 프로그램은 데이터베이스에 액세스할 때 가능한 가장 낮은 수준의 권한을 사용해야 합니다.
• 데이터베이스 액세스에 보안 자격 증명 사용
• 연결 문자열은 응용 프로그램 내에서 하드 코딩하면 안 됩니다. 연결 문자열은 신뢰할 수 있는 시스템의 별도 구성 파일에 저장하고 암호화해야 합니다.
• 저장 프로시저를 사용하여 데이터 액세스를 추상화하고 데이터베이스의 기본 테이블에 대한 권한 제거를 허용합니다.
• 가능한 한 빨리 연결을 닫으십시오.
• 모든 기본 데이터베이스 관리 비밀번호 제거 또는 변경
• 불필요한 데이터베이스 기능을 모두 끄십시오.
• 불필요한 기본 공급업체 콘텐츠(예: 샘플 스키마) 제거
• 비즈니스 요구 사항을 지원하는 데 필요하지 않은 기본 계정을 비활성화합니다.
• 응용 프로그램은 모든 트러스트 구별(예: 사용자, 읽기 전용 사용자, 게스트, 관리자)에 대해 서로 다른 자격 증명을 사용하여 데이터베이스에 연결해야 합니다.

파일 관리

• 사용자 제공 데이터를 동적 포함 기능에 직접 전달하지 마십시오.
• 파일 업로드를 허용하기 전에 인증이 필요합니다.
• 업로드할 수 있는 파일의 종류를 업무상 필요한 종류로만 제한
• 파일 확장자가 아닌 파일 헤더를 확인하여 업로드된 파일이 예상 유형인지 확인
• 애플리케이션과 동일한 웹 컨텍스트에 파일을 저장하지 마십시오.
• 웹 서버에서 해석될 수 있는 파일의 업로드를 방지하거나 제한합니다.
• 파일 업로드 디렉터리에 대한 실행 권한 해제
• 연결된 경로 또는 chrooted 환경을 사용하여 대상 파일 디렉토리를 논리 드라이브로 마운트하여 UNIX에서 안전한 업로드 구현
• 기존 파일을 참조할 때 허용된 파일 이름 및 유형의 허용 목록을 사용합니다.
• 사용자 제공 데이터를 동적 리디렉션에 전달하지 마세요.
• 디렉터리 또는 파일 경로를 전달하지 말고 미리 정의된 경로 목록에 매핑된 인덱스 값을 사용하십시오.
• 절대 파일 경로를 클라이언트에 보내지 않음
• 애플리케이션 파일 및 리소스가 읽기 전용인지 확인
• 사용자가 업로드한 파일에서 바이러스 및 맬웨어 검사

메모리 관리

• 신뢰할 수 없는 데이터에 대한 입력 및 출력 제어 활용
• 버퍼가 지정된 만큼 큰지 확인하십시오.
• 바이트 수를 허용하는 함수를 사용할 때 NULL 종료가 올바르게 처리되는지 확인하십시오.
• 루프에서 함수를 호출하는 경우 버퍼 경계를 확인하고 오버플로로부터 보호
• 다른 함수에 전달하기 전에 모든 입력 문자열을 적당한 길이로 자릅니다.
• 특히 리소스를 닫고 가비지 수집에 의존하지 마십시오.
• 가능한 경우 실행 불가능한 스택 사용
• 알려진 취약한 기능의 사용을 피하십시오
• 기능 완료 시 및 모든 종료 지점에서 할당된 메모리를 적절하게 비웁니다.
• 함수의 모든 종료 지점에서 할당된 메모리에 저장된 민감한 정보를 덮어씁니다.

일반적인 코딩 방법

• 일반적인 작업을 위해 새 비관리 코드를 만드는 대신 테스트되고 승인된 관리 코드를 사용합니다.
• 작업별 기본 제공 API를 활용하여 운영 체제 작업을 수행합니다. 애플리케이션이 운영 체제에 직접 명령을 내리도록 허용하지 마십시오. 특히 애플리케이션 시작 명령 셸을 사용하여
• 체크섬 또는 해시를 사용하여 해석된 코드, 라이브러리, 실행 파일 및 구성 파일의 무결성을 확인합니다.
• 잠금을 활용하여 여러 동시 요청을 방지하거나 동기화 메커니즘을 사용하여 경합 상태 방지
• 부적절한 동시 액세스로부터 공유 변수 및 리소스 보호
• 선언 중 또는 처음 사용하기 직전에 모든 변수 및 기타 데이터 저장소를 명시적으로 초기화합니다.
• 응용 프로그램이 상승된 권한으로 실행되어야 하는 경우 가능한 한 늦게 권한을 높이고 가능한 한 빨리 삭제하십시오.
• 프로그래밍 언어의 기본 표현을 이해하여 계산 오류 방지
• 사용자 제공 데이터를 동적 실행 함수에 전달하지 마십시오.
• 사용자가 새 코드를 생성하거나 기존 코드를 변경하지 못하도록 제한
• 모든 보조 애플리케이션, 타사 코드 및 라이브러리를 검토하여 비즈니스 필요성을 결정하고 안전한 기능을 검증합니다.
• 암호화된 채널을 사용하여 안전한 업데이트 구현

출처 : https://owasp.org/www-project-secure-coding-practices-quick-reference-guide/stable-en/02-checklist/05-checklist.html