Rails의 기본 필터링은 email_address, password_digest와 같은 요청 파라미터뿐만 아니라, User 객체와 같은 모델 인스턴스의 관련 속성에도 적용되어 민감한 정보가 로그에 기록되는 것을 방지합니다. 특히, encrypts를 통해 암호화된 phone_number와 같은 속성은 내부 요청 로깅 시에도 자동으로 필터링되어 나타나, 개발자가 별도로 필터링 목록을 업데이트할 필요성을 줄여줍니다. 그러나 모든 상황이 Rails의 기본 필터링으로 해결되는 것은 아닙니다. 예를 들어, Faraday와 같은 외부 HTTP 클라이언트를 사용하여 요청을 로깅할 경우, Rails의 필터링 설정이 자동으로 적용되지 않아 api_key나 사용자 객체의 민감한 속성(예: email_address, password_digest, phone_number)이 로그에 그대로 노출될 위험이 있습니다. 이는 보안상 매우 취약한 지점이 될 수 있습니다.
이러한 문제를 해결하기 위해, 본문에서는 Rails의 기존 필터링 설정을 재활용하는 커스텀 Faraday 로깅 포맷터인 ApplicationFormatter를 구현하는 방법을 제시합니다. 이 커스텀 포맷터는 Faraday::Logging::Formatter를 상속받아 request 및 response 메서드를 오버라이드하고, Rails의 Rails.configuration.filter_parameters와 ActiveSupport::ParameterFilter를 활용하여 요청 URL과 본문에서 민감한 파라미터를 필터링하도록 설계되었습니다. 이를 통해 api_key와 같은 정보가 Faraday 로그에서도 성공적으로 [FILTERED] 처리되며, 사용자 객체의 민감 속성 또한 노출되지 않습니다. 이 방식은 중복 노력을 피하고 일관된 보안 로깅 정책을 유지하는 데 기여합니다.
한편, Rails의 기본 필터링 목록을 업데이트하는 대신, id, _id, _at, _on과 같이 식별자 및 시간 관련 필드를 제외한 모든 파라미터를 필터링하는 ‘허용 목록(Allow List)’ 방식을 고려할 수도 있습니다. 이 방식은 lambda를 사용하여 filter_parameters에 추가함으로써 구현되며, 이름(name)과 같이 새롭게 추가된 컬럼도 자동으로 필터링하는 이점을 제공합니다. 이는 헬스케어와 같이 엄격한 규제 준수가 요구되는 애플리케이션에 적합할 수 있습니다. 하지만 이 접근 방식은 commit과 같은 일반적인 파라미터까지 필터링하여 디버깅 경험을 저해할 수 있으며, Faraday 로깅 시에도 전체 URL이나 데이터 해시가 필터링되는 등 과도한 정보 은닉으로 인해 로그의 유용성이 크게 떨어질 수 있다는 단점을 가집니다.