프론트엔드 보안의 한계와 서버의 책임

 

프론트엔드 개발을 하다 보면, UI 요소의 접근을 제어하는 기능을 종종 구현하게 됩니다.

 

예를 들어, 다음과 같이 삭제 버튼을 숨기거나 비활성화하는 방식입니다.

 

<dx:ASPxButton ID="btnDelete" runat="server" Text="삭제" Visible="false" />

 

또는

<dx:ASPxButton ID="btnDelete" runat="server" Text="삭제" Enabled="false" />

 

이러한 처리는 사용자 인터페이스 상에서는 해당 기능이 차단된 것처럼 보이지만, 보안적인 측면에서는 완전한 차단이 아닙니다. 이는 단지 UI 상의 제어일 뿐이며, 클라이언트 측 조작을 통해 쉽게 우회할 수 있습니다.

---

프론트엔드에서의 UI 제어는 보안 조치가 아니다

• Visible="false"로 설정된 버튼은 HTML에 렌더링되지 않지만, 사용자는 개발자 도구나 네트워크 탭을 통해 서버 요청 패턴을 분석하고 직접 요청을 보낼 수 있습니다.
• Enabled="false"로 설정된 버튼은 HTML 상에서는 disabled 속성으로 비활성화되지만, JavaScript로 해당 속성을 제거함으로써 기능을 실행할 수 있습니다.

// 비활성화된 버튼을 강제로 활성화하는 예제 
const btn = document.getElementById("btnDelete"); 
btn.removeAttribute("disabled"); btn.click();

 

또는 ASP.NET WebForms 환경에서는 다음과 같이 직접 콜백을 호출하는 방식도 가능합니다:

__doPostBack('btnDelete', '');

 

 

---

보안의 핵심은 언제나 서버에서의 권한 검증

UI 요소의 제어는 사용자 편의성과 UX 측면에서는 유용하지만, 보안적인 역할은 하지 못합니다. 사용자가 특정 기능을 수행할 수 있는지에 대한 판단은 반드시 서버에서 검증되어야 합니다.

ASP.NET WebForms 예시

protected void btnDelete_Click(object sender, EventArgs e) { 
    if (Session["Role"].ToString() != "Admin") {
        Response.Redirect("/AccessDenied.aspx"); 
        return; 
    } 
    DeleteData(); 
}

 

또는 페이지 로드 시 권한 검사:

protected void Page_Load(object sender, EventArgs e) { 
    if (!User.IsInRole("Admin")) { 
    	Response.Redirect("/AccessDenied.aspx"); 
    } 
}

 

Spring Boot + Spring Security 예시

스프링에서는 아래와 처럼 서버에서 검증하는 작업을 합니다.

 

애노테이션을 통한 접근 제어:

@PreAuthorize("hasRole('ADMIN')") 
@PostMapping("/api/delete") 
public ResponseEntity<?> deleteSomething() {
    // 삭제 로직 
}

 

또는 서비스 내 권한 검증:

@PostMapping("/api/delete") 
public ResponseEntity<?> delete(@RequestBody DataDto dto, Principal principal) { 
    String userId = principal.getName();
    
    if (!authService.canDelete(userId, dto.getId())) {
    	return ResponseEntity.status(HttpStatus.FORBIDDEN).build(); 
    } 
    service.delete(dto.getId()); 
    return ResponseEntity.ok().build(); 
}

---

대형 서비스 기업의 보안 전략은?

네이버나 카카오와 같은 대기업은 단순히 UI를 제어하는 수준을 넘어서, 다층적인 보안 체계를 도입하고 있습니다.

주요 보안 전략 예시

1. 모든 API 요청은 인증 토큰 기반 처리
2. API Gateway 또는 Security Filter를 통한 Role 기반 검증
3. 서버 로직에서 소유자 여부까지 철저히 검증
4. 요청과 응답은 로깅되어 이상 행위 탐지 및 감사 활용

if (!currentUser.equals(post.getAuthor())) {
	throw new ForbiddenException("해당 리소스에 대한 접근 권한이 없습니다."); 
}

 

---

핵심 정리

프론트엔드 (HTML, JS)	UI 제어, UX 제공	❌ 보안 불가 (조작 가능)
서버 (ASP.NET, Spring 등)	인증, 인가, 데이터 처리	✅ 보안 주체 (검증 필수)

---

마무리

프론트엔드에서 버튼을 숨기거나 비활성화한다고 해서, 기능이 완전히 차단되었다고 착각해서는 안 됩니다.

 

클라이언트는 언제든지 조작 가능하며, 이러한 제어는 단지 사용자 경험 개선용일 뿐입니다.

 

진정한 보안은 항상 서버 측에서 인증 및 인가 로직을 통해 이루어져야 하며, 프론트엔드는 이를 보조하는 역할일 뿐이라는 점을 잊지 마세요.

 

보안은 사용자 눈에 보이는 것이 아니라, 시스템 내부에서 철저히 검증되어야 합니다.