Laravel에서 런타임 요청 검사 탐구 (Guards, Contexts, and Tradeoffs)

Source: Dev.to

Introduction

런타임에 요청을 검사하는 Laravel 패키지를 실험하고 있습니다. 즉, 요청이 프레임워크에 들어온 뒤(컨트롤러에 도달하기 전이 아니라) 검사합니다.

이 아이디어는 해결책이라기보다 질문에서 시작되었습니다:

프레임워크 내부의 런타임 컨텍스트가 정적 요청 검사보다 더 나은 보안 신호를 제공할 수 있을까?

이를 탐구하기 위해, 요청이 Laravel 내부에 들어온 뒤 RuntimeContext 를 생성하고, 그 위에 Guards 파이프라인을 실행하는 패키지를 프로토타입했습니다.

RuntimeContext

• 정규화된 요청 데이터(헤더, 바디, 라우트 정보)
• 실행 메타데이터
• 선택적 히스토리 신호

Guards

• 작고 집중된 검사기
• 우선순위 기반 실행
• 단락(short‑circuit) 또는 결과 집계 가능
• 구조화된 GuardResult 객체 반환

Guard Characteristics

• 설정 가능하며 런타임에 활성화/비활성화 가능
• 각 Guard는 정의된 비용 / 우선순위를 가짐

Profiles

• 라우트 또는 사용 사례별로 Guard 그룹화
• API와 관리자 라우트에 대한 다른 동작
• 다양한 적용 모드 제공

Response Modes

Example Guard Types (not exhaustive)

• SQL 인젝션(패턴 기반 + 휴리스틱)
• XSS 지표
• SSRF 시도(내부 IP, 메타데이터 엔드포인트)
• 대량 할당 남용
• PHP 역직렬화 벡터
• NoSQL 연산자 인젝션
• GraphQL 깊이/복잡도 남용
• 봇 및 이상 행동(실험적)

Performance Considerations

• Deduplication cache 를 이용해 반복되는 페이로드 캐시
• Sampling – 요청의 일정 비율만 검사하고, 의심되는 요청은 항상 검사
• Tiered inspection – 빠른 스캔 → 깊은 스캔 순서로 진행
• Guard‑level and pipeline time budgets 설정

이 실험은 신호 품질과 오버헤드 사이의 균형을 맞추는 것이 목표이며, 실제 프로덕션 트래픽에서 아직 검증되지 않았습니다.

Limitations

• 검증을 대체하는 것이 아님
• WAF가 아님
• “모든 공격을 차단한다”는 주장 아님
• 프로덕션 사용 준비가 안 됨

이 프로젝트는 주로 Guard 구성, 런타임 컨텍스트 모델링, 신호 품질과 오버헤드 사이의 트레이드‑오프에 대한 설계 실험입니다.

Seeking Feedback

다음에 대한 의견을 구합니다:

• 아키텍처 선택
• Guard 인터페이스 설계
• 근본적인 결함 여부
• 더 나은 해결책을 제공하는 기존 프로젝트

다음 분야에 경험이 있다면:

• Laravel 내부 구조
• PHP 보안 도구
• 요청 라이프사이클
• 런타임 분석 시스템

…긍정적이든 부정적이든 생각을 공유해 주세요.

Links

• GitHub (source & issues):
• Packagist: