AI 아키텍처 기술 블로그

Insecure Design Secure Coding: Abuse Case·Rate Limit·업무 흐름 우회

Insecure Design은 보안 Header 하나를 빠뜨리거나 조건문 하나를 잘못 작성한 문제와 다릅니다. 필요한 통제 자체가 요구사항과 설계에 없으면 코드를 정확히 구현해도 시스템은 안전하지 않습니다.예를 들어 다음 코드는 모두 정상 동작할 수 있습니다.결제 완료 API가 요청되면 주문을 완료 상태로 바꿉니다.쿠폰 적용 API가 유효한 쿠폰의 할인액을 반환합니다.초대 API가 입력된 주소로 초대장을 보냅니다.보고서 API가 요청된 기간의 데이터를 집계합니다.하지만 결제 증명 없이 완료 API를 호출할 수 있고, 같은 쿠폰을 동시에 두 번 쓸 수 있고, 초대 횟수와 보고서 범위에 한도가 없다면 문제는 구현 Bug 이전에 누락된 보안 요구사항과 업무 불변식입니다.이 글은 2026년 8월 기준 OWASP..

Injection Secure Coding 심화: SQL·NoSQL·Command·Template Injection

Injection은 특수문자 몇 개를 막는 문제가 아닙니다. 외부에서 온 Data가 Database, Shell, Template Engine 같은 Interpreter의 구조나 명령으로 재해석되는 경로가 생기면 발생합니다.같은 입력도 어디에 도달하느냐에 따라 위험이 달라집니다.검색어가 Prepared Statement의 값으로 Bind되면 SQL Data입니다.같은 검색어가 Column 이름이나 ORDER BY 문자열에 연결되면 SQL 구조가 됩니다.JSON Object를 그대로 MongoDB Filter로 넘기면 Client가 Query Operator를 선택할 수 있습니다.문자열 배열로 Process를 실행해도 공격자가 Option을 추가할 수 있으면 Argument Injection이 남습니다.안..

Cryptographic Failures Secure Coding: Password Hash·Token·Key 관리

강한 Algorithm 이름을 하나 선택했다고 암호 설계가 끝나는 것은 아닙니다. Password를 AES로 암호화하거나, JWT Signature만 확인하고 Audience를 검증하지 않거나, AES-GCM에서 같은 Key와 IV를 재사용하면 표면적으로는 암호화를 사용해도 보호 목표를 달성하지 못합니다.Cryptographic Failures는 다음과 같은 설계·구현·운영 실패를 함께 포함합니다.민감정보를 평문으로 저장하거나 전송합니다.Password에 SHA-256 같은 빠른 Hash를 사용합니다.JWT Algorithm, Issuer, Audience와 만료를 정확히 검증하지 않습니다.암호 Key를 Source, Image, 환경 공용 설정이나 Log에 노출합니다.AES-GCM의 같은 Key·IV ..

Software Supply Chain Secure Coding: 의존성·SBOM·서명·배포 Gate

우리 코드가 안전해도 빌드에 들어온 라이브러리, Plugin, Base Image 또는 CI Action이 바뀌면 최종 Artifact는 달라집니다. 배포 파일이 정상적인 Source와 승인된 Build에서 만들어졌는지 확인하지 않으면, 취약한 의존성뿐 아니라 변조된 Build 과정도 운영에 들어갈 수 있습니다.Software Supply Chain 보안은 CVE Scan을 통과했는가라는 한 가지 질문으로 끝나지 않습니다.어떤 직접·전이 의존성이 실제로 포함됐는가?의존성을 어느 Repository에서 어떤 Byte로 받았는가?누가 어떤 Source Revision과 Build Workflow로 Artifact를 만들었는가?SBOM과 서명이 지금 배포하려는 Artifact Digest에 연결돼 있는가?운영..

Security Misconfiguration Secure Coding: CORS·Debug·기본 계정·보안 Header

애플리케이션 코드에 SQL Injection이 없어도 운영 설정 하나로 내부 정보가 외부에 노출될 수 있습니다. 개발 편의를 위해 열어 둔 CORS, 상세 오류, Actuator Endpoint와 기본 계정은 배포 환경이 바뀌는 순간 공격 표면이 됩니다.Security Misconfiguration은 특정 코드 한 줄의 결함이라기보다 안전한 기본값, 환경별 차이, 배포 검증이 함께 무너진 상태입니다.모든 Origin을 허용하면서 Cookie 인증도 사용합니다.운영 API가 Stack Trace, SQL 문장과 파일 경로를 반환합니다./actuator/env, /heapdump 또는 관리 Console이 외부에 열려 있습니다.설치 직후의 관리자 계정과 Password가 그대로 남아 있습니다.Gateway에..

Broken Access Control Secure Coding: IDOR·권한 우회·Tenant 격리

인증에 성공했다는 사실은 모든 데이터와 기능을 사용할 수 있다는 뜻이 아닙니다. 인증(Authentication)은 요청자가 누구인지 확인하고, 인가(Authorization)는 그 주체가 이 리소스에 이 동작을 수행해도 되는지 판단합니다.Broken Access Control은 이 두 번째 판단이 빠지거나 서로 다른 경로에서 일관되지 않을 때 발생합니다.URL의 주문 ID를 다른 값으로 바꿨더니 다른 고객의 주문이 보입니다.일반 사용자가 관리자 Endpoint를 직접 호출할 수 있습니다.Tenant A 사용자가 Tenant B의 파일이나 Export 결과를 내려받습니다.수정 DTO에 role, ownerId, tenantId를 추가했더니 보호 필드가 바뀝니다.단건 조회는 막았지만 목록, 검색, 캐시와 ..

고객 Mobile·Web에서 Server SDK와 Private API까지: End-to-End 통합 예제

운영 중인 서비스에 API 서버, 웹 페이지와 모바일 앱이 이미 있어도 고객사가 원하는 화면과 업무 흐름은 서로 다를 수 있습니다. 이때 고객별 앱과 웹을 모두 대신 개발하면 변경 속도와 운영 책임이 한곳에 집중됩니다.다른 선택은 고객사가 자신의 UX를 구현하도록 Android Kotlin, iOS Swift와 React JavaScript SDK를 제공하는 것입니다. 다만 핵심 API가 프라이빗 망에 있다면 Mobile·Web SDK가 그 API를 직접 호출하게 만들 수 없습니다. 고객 채널은 고객사 Backend for Frontend(BFF) 또는 Channel API를 호출하고, 그 서버가 Java Server SDK를 통해 프라이빗 API와 통신해야 합니다.이 글은 앞서 다룬 SDK 아키텍처, ..

OWASP Top 10:2025로 시작하는 Secure Coding: SQL Injection·Brute Force·Log Forging 방어

OWASP Top 10:2025로 시작하는 Secure Coding: SQL Injection·Brute Force·Log Forging 방어보안 코딩(Secure Coding)은 위험한 문자열 몇 개를 차단하는 규칙이 아닙니다. 신뢰할 수 없는 입력이 데이터베이스 Query, 인증 판단과 운영 Log로 이동할 때 데이터가 명령으로 해석되지 않게 하고, 반복 공격을 제어하며, 남겨진 증거를 신뢰할 수 있게 만드는 개발 방식입니다.SQL Injection, Brute Force와 Log Forging은 오래 알려진 공격이지만 지금도 중요합니다.SQL Injection은 입력값이 SQL 명령의 구조를 바꾸게 합니다.Brute Force는 인증 기능을 대량의 추측 요청을 처리하는 Password Oracle로..

AI 에이전트 시크릿 가드 설계: 커밋·파일 쓰기·로그·외부 전송으로의 유출 막기

사람 개발자도 시크릿을 실수로 커밋합니다. 그런데 AI 코딩 에이전트는 그 유출면을 더 넓힙니다. 에이전트는 파일을 쓰고, git add·git commit을 실행하고, 턴마다 프롬프트·출력을 로그로 남기고, 때로는 컨텍스트를 외부 모델·웹으로 보냅니다. 각 지점이 시크릿이 새어 나갈 수 있는 표면입니다. 그리고 시크릿은 한 번 커밋 히스토리에 들어가면 되돌리기 어렵습니다.이 글은 AI 에이전트가 만드는 시크릿 유출면을 정리하고, 그것을 방어 심층 (Defense in Depth) 으로 막는 설계를 다룹니다. 핵심 원칙은 하나입니다 — 애초에 시크릿을 값으로 다루지 말 것. 그 위에 쓰기·커밋 가드, 다층 탐지, 로그 마스킹, 외부 전송 게이트, 그리고 유출 시 대응(회전·폐기)까지 층층이 쌓습니다.이 ..

생성기를 위한 골든 테스트: 결정성·정규화와 무의미한 스냅샷 피하기

코드 스캐폴더, 템플릿 렌더러, 직렬화기, 포매터, 리포트·문서 생성기 — 이들의 공통점은 입력을 받아 구조화된 출력을 만든다는 것입니다. 이런 생성기에서 가장 무섭고 흔한 사고는 "관계없어 보이는 변경 하나가 출력을 조용히 바꿔 모든 사용처에 퍼지는 것"입니다. 이걸 가장 싸게 잡는 안전망이 골든 테스트 (Golden Test) 입니다. 알려진 정답 출력을 "골든" 파일로 고정해 두고, 매번 생성 결과와 대조하는 방식입니다. 흔히 스냅샷·승인·특성화 테스트와 묶어 부르지만 결이 조금씩 다릅니다 — 스냅샷 테스트는 프레임워크가 저장·비교를 지원하는 구현 방식, 승인 테스트는 사람이 결과를 검토·승인하는 워크플로, 특성화 테스트는 기존 시스템의 현재 동작을 기록하는 목적(골든 방식을 쓸 수 있음)입니다. ..