클라이언트 측 Javascript에서 데이터베이스로 직접 이동하지 않는 이유가 있습니까?

가능한 중복 :
웹 "서버 이하"응용 프로그램 작성

따라서 Stack Exchange 복제본을 구축하고 백엔드 저장소로 CouchDB와 같은 것을 사용하기로 결정했다고 가정 해 봅시다. 내장 인증 및 데이터베이스 레벨 권한 부여를 사용하는 경우 클라이언트 측 Javascript가 공개적으로 사용 가능한 CouchDB 서버에 직접 쓰지 못하게 할 이유가 있습니까? 이것은 기본적으로 CRUD 응용 프로그램이며 비즈니스 논리는 "작성자 만 자신의 게시물을 편집 할 수 있습니다"로 구성되므로 클라이언트 쪽 항목과 데이터베이스 사이에 계층이 필요하지 않습니다. CouchDB 측에서 유효성 검사를 사용하여 누군가가 가비지 데이터를 넣지 않도록하고 사용자가 자신의 _user 데이터 만 읽을 수 있도록 권한이 올바르게 설정되어 있는지 확인합니다. 렌더링은 AngularJS와 같은 방식으로 클라이언트 측에서 수행됩니다. 본질적으로 당신은 CouchDB 서버와 많은 "정적"페이지를 가질 수 있고 당신은 갈 수 있습니다. HTML 페이지를 제공 할 수있는 서버 측 처리는 필요하지 않습니다.

데이터베이스를 세계에 공개하는 것은 잘못된 것처럼 보이지만이 시나리오에서는 권한이 올바르게 설정되어있는 이유를 알 수 없습니다. 그것은 웹 개발자로서의 본능에 위배되지만 좋은 이유는 생각할 수 없습니다. 그렇다면 왜 이것이 나쁜 생각입니까?

편집 : 여기에 비슷한 토론이있는 것 같습니다 : 웹 "서버 이하"응용 프로그램 작성

편집 : 지금까지 멋진 토론, 나는 모든 사람의 의견에 감사드립니다! CouchDB와 AngularJS를 구체적으로 호출하는 대신 몇 가지 일반적인 가정을 추가해야한다고 생각합니다. 따라서 다음과 같이 가정하십시오.

• 데이터베이스는 숨겨진 저장소에서 직접 사용자를 인증 할 수 있습니다
• 모든 데이터베이스 통신은 SSL을 통해 이루어집니다
• 데이터 유효성 검사 는 데이터베이스에서 처리 할 수 있지만 처리해서는 안됩니다.
• 우리가 관리자 기능 이외의 관심을 가지는 유일한 권한은 자신의 게시물 만 편집 할 수있는 사람입니다
• 모든 사람이 모든 데이터 (비밀번호 해시를 포함 할 수있는 사용자 레코드 제외)를 읽을 수 있다는 점에서 완벽합니다.
• 관리 기능은 데이터베이스 인증에 의해 제한됩니다
• 아무도 관리자 역할에 자신을 추가 할 수 없습니다
• 데이터베이스는 확장하기가 비교적 쉽습니다.
• 진정한 비즈니스 로직은 거의 없거나 전혀 없습니다. 이것은 기본 CRUD 앱입니다

제안한대로 클라이언트 측 언어와 데이터베이스간에 긴밀한 연결을 만듭니다.

작성 및 유지 관리 할 코드가 적고 이론적으로는 디버깅이 더 빨라질 수 있습니다.

반면에, 그것은 다른 측면을 더 어렵게 만듭니다. 이러한 기술 중 하나를 변경해야 할 경우 기술이 밀접하게 결합되어 시간이 더 어려워집니다.

공격으로부터 자신을 보호하는 것은 조금 더 어려울 것입니다. 클라이언트는 항상 형식이 좋은 요청을 데이터베이스에 제시한다고 가정합니다. 그것은 아무도 악의적 인 진술을 삽입하기 위해 클라이언트 측 코드를 해킹하지 않을 것으로 추정합니다. 즉, 인증 메커니즘을 "빌려"일반 클라이언트 코드를 인증 메커니즘으로 바꿉니다.

나는 그것을 추천하지 않을 것이고, 많은 사람들은 당신에게하지 말라고 격렬하게 말할 것입니다. 그러나 할 수 있습니다.

아마 좋은 생각이 아닙니다. 그리고 내가 줄 수있는 첫 번째이자 가장 강력한 이유 는 데이터베이스 서버가 공용 웹 서버로 설계 되지 않았기 때문 입니다 . 반대로, 기존의 지혜는 데이터베이스를 방화벽 뒤에 숨겨야한다고 말합니다.

근거를 뒷받침하는 증거가 필요한 경우, 극복 할 수없는 것이 아니라 생각해야 할 것이 많습니다. 특별한 순서는 다음과 같습니다.

• 당신이 그것을 쿼리를 전송하고 있기 때문에, 쿼리 위생을 수행 할 수 없습니다 직접.
• 데이터베이스 권한은 웹 서버 및 응용 프로그램 권한과 다르게 작동하는 경향이 있습니다. 웹 서버 및 응용 프로그램 프레임 워크는 아무 것도없이 시작하므로 개별 리소스, 엔드 포인트 및 작업을 명시 적으로 생성하고 노출해야합니다. 반면 데이터베이스는 높은 수준에서 역할을 부여하도록 요청합니다.
• 웹 서버의 작업량을 유지하는 데 적합하지 않을 수 있습니다. 연결 풀링의 이점은 없습니다.
• 더 인기있는 웹 서버는 많이 나 broken습니다 . 그리고 많은 보안 패치를 받았습니다. DBMS는 기본적으로 방화벽 뒤에 숨겨 지도록 설계되었으므로 아마도 퍼블릭 웹에서 발생할 수있는 잠재적 위협의 일부에 대해서는 테스트되지 않았을 것입니다.
• 당신은 있어야합니다 개인 데이터를 보호하기 위해 데이터베이스의 쿼리 언어를 사용합니다. DBMS에 따라 이는 어려울 수 있습니다.
• 당신은 해야한다 대규모 데이터 세트를 필터링 할 데이터베이스의 쿼리 언어를 사용 - 어쨌든 수행하기 위해 노력하고 있습니다 뭔가를; 그러나보다 복잡한 비즈니스 규칙에 부담이 될 수있는 것.
• 타사 라이브러리에 대한 지원이 제한적이거나 지원되지 않습니다.
• 발생할 수있는 많은 문제에 대해 매우 제한적인 커뮤니티 지원.

... 그리고 다른 걱정이있을 것입니다. 그리고 이러한 우려가 전부는 아니지만 대부분의 해결책이 있다고 확신합니다. 그러나 시작하기위한 목록이 있습니다!

내가 상상할 수있는 가장 좋은 단일 이유는이 방법이 관련 당사자가 직접 지원하거나 권장하지 않기 때문입니다.

브라우저 공급 업체, EcmaScript 표준, 데이터베이스 시스템 개발자, 네트워킹 장비 회사, 호스팅 / 인프라 설계자 및 보안 전문가는 제안 된 사용 사례를 적극적으로 지원하거나 고려하지 않습니다. 제안 된 방법에는 관련된 모든 시스템이이를 지원하도록 설계되지 않았더라도 제안 된 방법에서 응용 프로그램에 대해 적절하게 작동하기 위해 이러한 엔티티 등이 모두 필요하기 때문에 문제가됩니다.

불가능하다는 말은 아닙니다. 나는 이것이 "바람 재발견"과 같지 않으며 브라우저 기반 클라이언트-서버 상호 작용을 재발 명하는 것과 비슷하다고 말합니다.

기껏해야 시스템이 가장 기본적인 수준에서 작동하도록하기 위해 많은 작업을 수행하게됩니다. 현대의 인기있는 데이터베이스는 RESTful이 아니거나 HTTP를 통해 작동하도록 구축되지 않았으므로 고유 한 WebSocket 기반 (I- 추정) 클라이언트 드라이버를 빌드하게됩니다.

기술적으로 모든 작업을 수행하더라도 최신 아키텍처의 가장 강력한 기능을 많이 포기하게됩니다. 심층적 인 방어 기능은 없습니다. 모든 사람이 대부분의 웹 사이트 해킹 시도의 주요 대상에 직접 연결할 수 있습니다. 그러나 당신이 제안하는 시나리오는 그것보다 훨씬 나쁩니다.

제안 된 모델은 서버를 노출시키는 것이 아니라 유효한 연결 문자열을 노출시키는 것입니다. 공격자는 서버를 핑할 수 없으며 적극적으로 로그인하여 명령을 제공 할 수 있습니다. 데이터 액세스를 제한 할 수 있다고해도 DBMS 시스템의 서비스 거부 시나리오와 그 영향으로부터 보호 할 수있는 도구가 충분하지 않습니다. TSQL과 같은 고급 버전의 SQL에서 작업 할 때 무한히 효과적으로 실행되는 폭탄을 생성하는 것이 쉬운 경우가 종종 있습니다 (카테 시안 제품을 만들기 위해 무제한으로 조인하면 많은 작업을 수행 할 수있는 SELECT가 있음) . JOIN을 사용하여 기본 SELECT 쿼리를 제거하고 저장 프로 시저 호출 만 허용하더라도 SQL 기능의 대부분을 비활성화해야한다고 생각하십니까? 당신이 그렇게 할 수 있는지조차 모르겠습니다. 그렇지 않습니다

또한 데이터베이스 확장 성은 대규모 작업에서 가장 어려운 문제 중 하나 인 반면, 특히 정적 또는 캐시 된 페이지가있는 여러 HTTP 서버를 확장하는 것이 가장 쉬운 부분 중 하나입니다. 귀하의 제안은 기본적으로 서버 측 활동의 100 %를 담당함으로써 데이터베이스가 더 많은 작업을 수행하도록합니다. 그것은 그 자체로 살인자 결점입니다. 더 많은 작업을 데이터베이스로 이동하여 작업을 클라이언트로 이동하여 얻는 것.

마지막으로, 나는 당신이 제안하는 것의 핵심이 새로운 것이 아니라 실제로 수십 년 전으로 돌아가고 있음을 지적하고 싶습니다. 이 모델을 "뚱뚱한 데이터베이스"모델이라고하며, 기본적으로 대부분의 서버 측 로직을 제안한대로 데이터베이스로 옮깁니다. 대중 인터넷에서 모델이 길을 잃은 데는 여러 가지 이유가 있으며 아마도 그 역사를 더 자세히 살펴 보는 것이 유익 할 것입니다. 또한 시스템을 지속적으로 공격하지 않아야하는 내부 (알려진) 사용자를 선택하도록 액세스를 제어 할 수 있기 때문에 완전히 신뢰할 수없는 사용자가 시스템에 로그인하고 명령을 실행할 수 있다는 점에 대해서는 거의 고려하지 않았습니다.

사실 데이터베이스 시스템은 그렇게하지 않기 때문에 파일을 제공하기 위해 여전히 HTTP 서버가 필요하다는 것입니다. 동시에 씬 서버 모델 (예 : Nodejs)을 사용하여 RESTful 인터페이스를 데이터베이스에 노출하면 제안한 모든 것을 얻을 수 있습니다. 이 방법은 인기가 있습니다. 작동하고, 보호 계층 뒤에 데이터베이스를 숨기고, 확장 성이 뛰어나면서도 원하는만큼 데이터베이스를 두껍거나 얇게 만들 수 있습니다.

이것은 기본적으로 CRUD 응용 프로그램이며 비즈니스 논리는 "작성자 만 자신의 게시물을 편집 할 수 있습니다"로 구성되므로 클라이언트 쪽 항목과 데이터베이스 사이에 계층이 필요하지 않습니다. CouchDB 측에서 유효성 검사를 사용하여 누군가가 가비지 데이터를 넣지 않도록하고 사용자가 자신의 _user 데이터 만 읽을 수 있도록 권한이 올바르게 설정되어 있는지 확인합니다.

글쎄, 당신의 배치 권한 데이터베이스에서 멀리 (보안 문제) 및 로직 검증하는 것은 문제의 분리를 제공하는 소프트웨어 시스템을. 따라서 시스템 기능의 제동 위험을 줄이면서 논리 코드 블록을 테스트, 유지 관리, 확장 및 재사용 할 수 있습니다.

클라이언트 입력이 데이터베이스와 직접 통신 할 수있는 기능을 제공 하면 데이터를 망칠 가능성 이 매우 높습니다 .

이는 또한 긴밀한 커플 링 을 피하거나 제거함으로써 소프트웨어 시스템을보다 유지 보수하고 SOLID로 만들 수 있음을 의미합니다 .

사용자가 데이터베이스와 직접 상호 작용하게하는 것은 정말 위험 해 보입니다.

CouchDB의 인증 메커니즘은 사용자가 읽고 쓸 데이터에 대해서만 읽기 및 쓰기 액세스를 분리 할 수 ​​있도록 매우 정교합니까? 특권)? 여러 사용자가 공유하는 "공동"데이터는 어떻습니까? 이것이 애플리케이션 디자인에 전혀 존재하지 않습니까?

사용자가 어떤 방식 으로든 데이터를 변경할 수 있기를 정말로 원하십니까? 예를 들어 XSS 주사는 어떻습니까? 데이터베이스에 들어가기 전에 서버 계층을 필터링하는 것이 더 좋지 않습니까?

여러 가지 이유가 있지만 여기에는 미래를위한 또 하나의 증거가 있습니다. 조만간 응용 프로그램이 발전함에 따라 클라이언트 쪽 JS에서 또는 데이터베이스의 저장 프로 시저로 쉽게 또는 안전하게 달성 할 수없는 몇 가지 요구 사항이 제공됩니다.

예를 들어, 모든 새로운 등록에는 유효한 CAPTCHA 확인이 필요하다는 메시지가 표시됩니다. 이것은 현대의 웹 응용 프로그램 프레임 워크와 거의 비슷합니다. 등록 양식에서 reCAPTCHA 를 때리고 reCAPTCHA의 응답 토큰을 백엔드로 다시 전달하고 백엔드에 몇 줄의 코드를 추가하여 Google API로 토큰의 유효성을 확인하십시오 (또는 다른 사람이 작성한 라이브러리를 사용하십시오) 당신을 위해).

2 계층 시스템을 사용하고 모든 서버 측 논리에 데이터베이스를 사용하는 경우 토큰을 어떻게 확인합니까? 예, DBMS에 따라 쉘을 호출하고 적절한 인수로 curl을 호출하는 저장 프로 시저를 작성하는 것이 이론적으로 가능하다고 가정합니다. 입력 필터링과 보안 취약점으로부터의 보호는 끔찍할 것입니다. 오류 처리 및 시간 초과를 다루는 혼란이 있습니다. 응답을 직접 파싱해야합니다. 말할 것도없이 DBMS는이를 수행하기위한 것이 아니므로 성능, 안정성, 스레드 안전성 등이 문제가되지 않는다고 생각할 이유가 없습니다. 예를 들어 Postgres의 이러한 문제에 대해 설명하는 이 스레드 를 참조하십시오 .

그리고 그것은 하나의 간단한 보안 문자를 양식에 추가하는 것과 관련된 문제 일뿐입니다. SMS 확인 또는 비활성 사용자에게 이메일을 보내 앱에 대해 알리거나 파일 업로드 기능을 추가하여 사람들이 프로필 사진을 설정할 수있는 백그라운드 작업을 추가하려면 어떻게 하시겠습니까? 언젠가 응용 프로그램에 언젠가 자동 테스트가 필요하다고 생각하십니까? 아니면 버전 관리 시스템에서 절차 변경 사항을 추적하고 싶습니까? 대부분의 유용한 언어에 대해 이러한 작업을 대부분 처리 할 수있는 수많은 라이브러리와 도구가 있지만 DBMS에서 사용할 수있는 것은 거의 없기 때문에 거의 없습니다.

결국, DBMS에서 합리적으로 직접 할 수없는 일을하고 싶을 것입니다. DBMS에서 전체 응용 프로그램을 구축 했으므로 간단한 기능을 추가하기 위해 웹 서버를 가져 와서 다른 언어로 조각을 다시 작성하는 것 외에 다른 대안이 없습니다.

우리는 이미 응용 프로그램 논리를 넣을 장소의 이름을 가지고 있으며, 이유 때문에 "데이터베이스 저장 프로 시저"가 아닌 "응용 프로그램의 소스 코드"라고 불렀기 때문에 이는 부끄러운 일입니다.

보안 검사 및 비즈니스 로직이 클라이언트 측 자바 스크립트에 포함되어 있으면 악의적 인 사용자가이를 무시할 수 있습니다. 대안으로, JavaScript 기반 서버 측 기술 (예 : Node.JS )을 활용하여 유효성 검증, 권한 부여 등을 처리 할 수 ​​있습니다.

확인하려는 비즈니스 제약 조건은 서버 측에서 확인해야합니다. 사용자 액세스를 제어하더라도 누군가가 잘못된 데이터를 보낼 수 있습니다.

stackoverflow 복제 예제를 따르면 :

• 어쨌든 사이트의 "닫힌"질문이 편집되는 것을 어떻게 차단 하시겠습니까?
• 사람들이 댓글을 삭제하지 못하게하려면 어떻게해야합니까?
• 사람들이 댓글 날짜를 속이는 것을 어떻게 막을 수 있습니까?
• 사람들이 같은 게시물을 50 배 올리는 것을 어떻게 막을 수 있습니까?
• 조금 더 파면 더 많은 예제가있을 것입니다.

누구나 자신의 게시물과 같은 특정 객체로 제한 되더라도 클라이언트 측 코드를 조작하고 데이터 무결성을 완전히 위반할 수 있습니다.

방화범에서 페이지를 편집하고 어느 시점에서 이와 비슷한 줄을 넣으십시오.

ExecDbCommand("DROP TABLE Users")

그것을 실행하십시오.

편집하다:

실제로 CounchDB에 대한 질문이 있었으므로 여기서 실행할 SQL이 없습니다. 그러나 아이디어는 동일합니다. 사소하지 않은 응용 프로그램은 응용 프로그램 코드에서 확인 / 강제하는 일부 일관성 규칙을 준수하기 위해 데이터에 의존한다고 가정합니다. 악의적 인 사용자는 클라이언트 코드를 수정하여 비즈니스 규칙을 위반하는 양식으로 데이터를 저장하여 응용 프로그램에 혼란을 줄 수 있습니다.

귀하의 사이트가 비즈니스 관점에서 유효 할 모든 가능한 데이터 상태를 고려한다면 반드시이 경로를 이동하지만이 경우 (가능성이) 다음이 저장됩니다 데이터에 의해 생성된다는 보장을 할 것이없는 경우 귀하의 코드 와 규칙 에 따라 .

오래된 질문이지만, 나는 알고 있지만 내 경험이 다른 반응과 상당히 다르기 때문에 차임하고 싶었습니다.

실시간 협업 애플리케이션을 작성하는 데 수년을 보냈습니다. 이러한 응용 프로그램에 대한 일반적인 접근 방식은 데이터를 로컬로 복제하고 변경 사항을 가능한 빨리 피어와 동기화하는 것입니다. 데이터에 대한 모든 작업은 로컬이므로 모든 데이터 저장소, 데이터 액세스, 비즈니스 논리 및 사용자 인터페이스는 로컬입니다. "오프라인 우선"운동 ( http://offlinefirst.org/ )은 오프라인 웹 애플리케이션을 빌드하기 위해이 접근 방식을 채택했으며 관련 리소스가있을 수 있습니다. 이러한 종류의 사용 사례는 클라이언트에게 데이터 액세스 계층을 열어야 할뿐만 아니라 데이터 스토리지도 요구합니다! 내가 알지. 미친 것 같아요?

이러한 오프라인 우선 앱에 대한 우려는 요청한 것과 유사하며 한 수준 만 제거되었습니다. 그것은 나에게 관련이있는 것 같습니다. 클라이언트에 대한 직접 데이터 액세스를 열면 악의적 인 사용자의 영향을 어떻게 제한 할 수 있습니까? 글쎄, 많은 전략이 있지만, 더 전통적인 개발 배경에서 온 것인지 분명하지 않습니다.

첫 번째 오해는 데이터베이스를 노출한다는 것은 모든 데이터를 노출한다는 의미입니다. 예를 들어 CouchDB를 보자. CouchDB의 데이터베이스는 가볍기 때문에 서버에서 수십만 개의 개별 데이터베이스를 만드는 것에 대해 다시 생각할 필요가 없습니다. 사용자는 판독기 또는 기록기로 액세스 할 수있는 권한이 부여 된 데이터베이스에만 액세스 할 수 있으므로 (CouchDB의 유효성 검사 기능 및 기타 기능은 제외) 데이터의 하위 세트에만 액세스 할 수 있습니다.

두 번째 오해는 사용자가 데이터를 크 래핑하는 것이 문제라는 것입니다! 사용자에게 데이터베이스 복제본이 제공되면 다른 사용자에게 영향을주지 않고 원하는 모든 것을 폐기 할 수 있습니다. 그러나 데이터를 "중앙"저장소로 다시 복제하기 전에 변경 내용을 확인해야합니다. Git에 대해 생각하십시오-사용자는 마스터 브랜치에 영향을 미치지 않고 브랜치, 포크 및 로컬 리포지토리에서 원하는 것을 할 수 있습니다. 다시 마스터로 합류하는 것은 많은 의식이 필요하며 맹목적으로 이루어지지 않습니다.

현재 CouchDB를 사용하여 사용자가 데이터에 대해 협업하여 QA / QC 워크 플로를 통해 "게시 된"데이터 세트를 구축해야하는 시스템을 구축하고 있습니다. 협업은 데이터 복제본 (이를 스테이징 또는 작업 데이터베이스라고 함)에서 수행되며, 완료되면 담당자가 데이터에 대해 QA / QC를 수행 한 후 데이터가 기본 저장소로 다시 복제됩니다.

기존의 3 계층 CRUD 애플리케이션에 대한 버전 제어, 복제 및 협업 (오프라인 작업과 함께!)과 같은 다른 시스템에서는 달성하기 어려운 많은 이점이 있습니다.

내 조언-응용 프로그램이 "전통적"인 경우 전통적인 방식으로 수행하십시오. 위에서 언급 한 것 (더 많은 것이 있지만 ...)이 적용된다면 대안 아키텍처를 고려하고 측면으로 생각할 준비를하십시오.

모든 가정이 주어지면 클라이언트에서 데이터베이스로 직접 이동하는 것이 가능하다고 생각합니다. 그러나 귀하의 가정이 유효한지, 앞으로도 계속 유지 될 가능성이 있는지 살펴 보는 것이 합리적입니다.

앞으로 모든 사람이 모든 데이터를 읽는 것이 좋지 않을 수 있으며 특히 미래에 더 많은 비즈니스 로직을 개발할 수 있을지 걱정됩니다. 프로젝트가 성공하면이 두 가지가 더 가능성이 높습니다.

미래에 이러한 문제를 해결할 수있는 방법을 남겨두고 실제로 문제를 해결할 필요가 있다면 디자인이 제대로 작동 할 것이라고 생각합니다. JavaScript 코드에서 우려 사항을 구분하기 위해 각별히주의해야하며 일부는 나중에 서버에서 다시 작성 될 수 있습니다.

그러나 나중에 그렇게 할 위험이있는 부분과 오늘날 움직이는 부품 수가 적다는 이점을 확실히 알 수있었습니다.

OUT OF THE BOX 질문에 감사드립니다 .... :)

그러나 내가 제안하는 것은; 항상 3 개의 계층간에 분리를 유지하십시오. 프레젠테이션 / 비즈니스 및 데이터베이스 또는 DAO는 매일 많은 변경이 필요한 요구 사항 및 설정에 가장 적합하기 때문입니다.

단순한 세계에서 프레젠테이션 계층은 데이터베이스 계층에 대해 알지 않아야합니다. 즉 일부 날짜 유형 필드의 형식은 프레젠테이션 계층 및 데이터베이스 계층과 다를 수 있으므로 사용자는 필요에 따라 날짜의 적절한 형식을 자유롭게 선택할 수 있습니다.

그리고 Business Logic은 프리젠 테이션 계층과 데이터베이스 / Dao 계층 사이의 필드 캐스팅, 일부 비즈니스 유효성 검사 등이 질문에 따라 Javascript 섹션이 아닌 비즈니스 계층에서 처리되어야합니다.

이 분리는 복잡한 시나리오, 기능 및 복잡한 검증 중에도 매우 쉽고 편리합니다. 가장 좋은 장점은 이러한 계층을 구현하기 위해 다양한 기술을 보유 할 수 있으며 비즈니스 요구 또는 범위에 따라 변경 될 수 있다는 것입니다.

감사

JavaScript로 SQL을 빌드하여 데이터베이스로 보내려면 보안상의 이유로보다 권한 등을 확인하십시오. 재해일 수 있습니다. API를 빌드하고 직접 쿼리를 작성할 때 보안 관점에서 제한된 수의 쿼리 만 분석해야하기 때문입니다. 쿼리가 시스템 외부에 구축 된 경우 다른 사람이 할 수있는 트릭 수에는 제한이 없습니다.

그러나 키 값 데이터베이스를 사용하고 있기 때문에 그렇지 않습니다 (공식적으로 CouchDB는 일반적으로 해당 범주에 속합니다). 데이터베이스 인터페이스 자체는 일종의 중간 계층이며 Apache 팀에서 보안상의 이유로 테스트했습니다. 비교적 간단한 JavaScript API로 인해 JSF 애플리케이션의 복잡한 인터페이스보다 잠재적 결함을 분석하기가 훨씬 쉽습니다.

복잡한 보안 테스트를 수행하는 경우 안전한 솔루션이 될 수 있습니다. 읽기 어려운 API를 사용하는 JSF와 같은 프레임 워크를 사용할 때보 다 훨씬 쉬울 수 있습니다. 모호한 보안은 해결책이 아닙니다.

귀하의 질문과 관련하여 어쨌든 데이터베이스에 직접 액세스 할 수는 없습니다. 직접 액세스는 JavaScript로 SQL 쿼리를 작성하는 것입니다 (불행히도 그러한 솔루션을 보았습니다). 귀하의 경우 CouchDB 자체는 격리 계층을 제공합니다. 물론 API로 랩핑하여 보안을 강화할 수 있지만 특정 사용자가 수행 할 수있는 작업을 쉽게 테스트 할 수 있고 보안 제약 조건이 적합한 경우 추가 계층없이 안전하고 강력한 솔루션을 확보 할 수 있습니다.

두 가지 문제가 있습니다.

1. 긴밀한 결합 : DB 옵션을 변경 하시겠습니까? 자, 이제 모든 클라이언트 측 코드도 변경해야합니다. 날 믿어. 클라이언트 쪽에서 더 이상 문제가 필요하지 않습니다.

2. TMI 보안 문제 : 작업 방식에 대해 너무 많이 공개합니다. 인증은 여전히 ​​장애가 될 수 있지만 서버 측에서 무슨 일이 일어나고 있는지 정확히 알면 악용을 찾는 것이 훨씬 쉽습니다.

매우 얇은 중간 계층이 더 나은 방법 일 수 있습니다.

자바 스크립트가 유일한 데이터베이스 액세스 계층 인 경우 자바 스크립트가 비활성화되어 있거나 장치의 브라우저에서 지원되지 않으면 클라이언트가 웹앱을 사용할 수 없습니다.