PHP 프레임워크: 피해야 할 숨겨진 오류

Symfony(작성 당시 7.2) 또는 Laravel과 같은 프레임워크는 사용자 정의가 가능하며 경험과 기술에 관계없이 모범 사례를 장려합니다.

그러나 여전히 디자인, 보안 또는 성능 문제가 발생할 수 있습니다.

Symfony: $container를 직접 호출하지 마세요

❌ 이것은 고전적이지만 여전히 개발자들이 많이 사용하는 것입니다.

 class LuckyController extends AbstractController
  {
      public function index()
       {
        $myDependency = $this->container->get(MyDependencyInterface::class);
        // 
       }

부모 AbstractController가 $container를 protected로 정의했기 때문에 가능합니다.

protected ContainerInterface $container;

출처: Symfony - GitHub

효과는 있지만 여러 가지 이유로 좋지 않은 습관입니다.

• 가독성에 해를 끼칩니다
• 테스트하기가 더 어렵습니다
• 전역 상태($container)에 의존합니다
• 향후 Symfony가 발전함에 따라 비호환성 문제가 발생할 수 있습니다

✅ 대신 생성자에서 종속성 주입을 사용하세요.

 class LuckyController extends AbstractController
  {
      public function __construct(private MyDependencyInterface $myDependency) {}

Eloquent ORM: 원시 쿼리를 맹목적으로 사용하지 마세요

Eloquent를 사용하면 SQL 쿼리를 매우 편리하게 작성할 수 있습니다.

개발자는 SQL 쿼리를 직접 작성하는 대신 PHP 래퍼를 사용하여 데이터베이스 엔터티와 상호 작용할 수 있습니다.

또한 배후에서 SQL 바인딩을 사용하므로 신뢰할 수 없는 입력에도 무료로 주입 방지 기능을 사용할 수 있습니다.

User::where('email', $request->input('email'))->get();

❌ 그러나 whereRaw와 같은 도우미를 사용하면 취약점이 발생할 수 있습니다.

User::whereRaw('email = "'. $request->input('email'). '"')->get();

✅ 적어도 항상 SQL 바인딩을 사용하세요.

User::whereRaw('email = :email', ['email' => $request->input('email')])->get();

주의: 위의 예는 이해가 되지 않지만 상황을 단순하게 유지합니다. 실제 사용 사례에서는 최적화 목적으로 또는 매우 구체적인 where 조건을 구현하기 위해 whereRaw가 필요할 수 있습니다.

Laravel: CSRF는 어떻습니까?

CSRF 공격을 통해 해커는 최종 사용자가 현재 인증된 앱에서 원치 않는 작업을 실행하도록 강제합니다.

Laravel에는 이러한 상황을 방지하는 메커니즘이 내장되어 있습니다.

대략 말하면 요청과 함께 보낼 토큰(숨겨진 필드)을 추가하므로 "인증된 사용자가 실제로 애플리케이션에 요청하는 사람"인지 확인할 수 있습니다.

그렇습니다.

❌ 그러나 일부 앱에서는 이 구현을 건너뜁니다.

✅ 내장된 미들웨어를 사용해야 하는지 여부는 여기서 관련이 없지만 앱이 CSRF 공격으로부터 보호되는지 확인하세요.

Laravel의 구현에 대한 자세한 내용은 이 페이지를 참조하세요.

AJAX 요청도 보호해 주세요.

Eloquent ORM: 쿼리는 "자동으로" 최적화되지 않습니다.

Eloquent는 즉시 로딩/지연 로딩을 허용하고 쿼리 캐싱, 인덱싱, 일괄 처리 등 다양한 최적화를 지원합니다.

그러나 특히 대규모 데이터세트의 경우 모든 성능 문제를 예방할 수는 없습니다.

❌ 이러한 루프를 보는 것은 드문 일이 아닙니다.

 class LuckyController extends AbstractController
  {
      public function index()
       {
        $myDependency = $this->container->get(MyDependencyInterface::class);
        // 
       }

그러나 메모리 문제가 발생할 수 있습니다.

✅ 가능하다면 Laravel 컬렉션과 청크와 같은 도우미를 활용하는 것이 더 나은 접근 방식입니다.

protected ContainerInterface $container;

자세한 내용은 설명서를 확인하세요.

주의: 작동하지만 이러한 도우미는 단지 구현을 쉽게 하기 위한 것이므로 느린 쿼리와 기타 병목 현상을 모니터링해야 한다는 점을 잊지 마세요.

심포니: SRP 서비스

문서에 나와 있는 대로:

유용한 개체를 서비스라고 하며 각 서비스는 서비스 컨테이너라는 매우 특별한 개체 안에 있습니다. 컨테이너를 사용하면 객체가 구성되는 방식을 중앙 집중화할 수 있습니다. 이는 귀하의 삶을 더 쉽게 만들고 강력한 아키텍처를 촉진하며 매우 빠릅니다!

즉, 애플리케이션에 대한 특정 책임을 처리하기 위해 사용자 정의 서비스를 작성하게 됩니다.

❌ 문서가 맞습니다. 강력한 아키텍처를 장려하는 것을 목표로 하지만 단일 책임 원칙(SRP)을 위반하는 서비스를 읽는 것은 드문 일이 아닙니다.

 class LuckyController extends AbstractController
  {
      public function __construct(private MyDependencyInterface $myDependency) {}

✅ 그 원칙을 존중해야 합니다. 테스트 및 유지 관리가 더 쉬워집니다.

Symfony: 공개 서비스와 비공개 서비스

❌ Symfony를 사용하면 $container->get('service_id')를 사용하여 모든 공공 서비스에 전화할 수 있습니다.

앞서 $container를 그렇게 호출하는 것은 나쁜 습관으로 간주된다는 점을 살펴보았습니다.

모든 서비스를 공개하고 싶은 유혹을 뿌리칠 수 없으므로 프로젝트 내 거의 모든 곳에서 해당 서비스를 ID로 검색할 수 있습니다.

그러지 마세요.

✅ 대신 대부분의 맞춤 서비스를 비공개로 유지하고 종속성 주입을 사용하세요.

마무리

제가 프레임워크에서 "잠재 오류" 또는 "숨겨진 오류"라고 부르는 현상을 피하시길 바랍니다.

구현 방법을 모른다면 프레임워크를 신뢰하세요. 하지만 일부 메커니즘은 기본적으로 활성화되지 않을 수 있다는 점에 유의하세요.

위 내용은 PHP 프레임워크: 피해야 할 숨겨진 오류의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!