애플리케이션에 대한 REST API를 디자인 할 때 일부 서비스는 공개로 간주되지만 다른 서비스는 비공개로 유지되는 것이 좋습니다 (즉, 공개적으로 액세스 할 수 없음). OAuth는 서비스 응용 프로그램에서 사용됩니다.RESTful 리소스에 대한 액세스 제한
조치 사항은 무엇입니까? 마음에
몇 가지 아이디어 :
중재자가 누구에게나 어떤 특정 사용자에게만 어떤 리소스를 사용할 수 있는지 알 수있는 가장 간단한 방법은 URL을 디자인하는 것입니다.
그런 다음 프록시 또는 서블릿 필터 또는 현재 필요로하는 모든 권한이 권한 부여를 수행하여 모든 권한없는 요청을 차단합니다. 실제 서비스는 맹목적으로 도달하는 모든 요청을 신뢰하고 서비스 할 수 있습니다.
관심사와 모든 사항이 분리되었습니다.
예 :
인증되지 않은 요청이 도달 할 수 있습니다 : 사용자 이름 "조"로 인증
/myapi/public
요청도에 도달 할 수 있습니다 :
/myapi/personal/joe
401 권한 :
/myapi/personal/anything_but_joe
을 엠/myapi/personal/otheruser 및/myapi/personal/nonexistentuser는 구분할 수없는 응답을 반환합니다.
잠재 고객의 특정 세그먼트에 대해 보호되고 제한되어야하는 모든 리소스는 적절한 액세스 제어 권한 (기본적으로 2 번에서 언급 한 내용)을 가져야합니다. 가이드로서 트위터와 같은 성공적인 서비스에서 API를 참조하면 항상 토큰이 관련되어 있음을 알 수 있습니다.
난독 화는 허용되지 않습니다. 이것은 단지 security through obscurity이며 근본적으로 결함이 있습니다. OWASP Top 10, failure to restrict URL access의 일부분을 잘 읽으십시오. RESTful이든 아니든 관계없이 동일한 규칙이 모든 리소스에 적용됩니다.
액세스 제어는 먼저 판단해야합니다. 깊이있는 보안은 추측하기 어려운 URL 일 것입니다. – Ellead
적절한 액세스 제어 대신에 거의 가치가 없으며 거의 쓸모가 없습니다. "보안은 약하지만 보안 통제가 약합니다."https://www.owasp.org/index.php/Avoid_security_by_obpurity –
예.이 경우 액세스 제어는 OAuth 토큰에 의해 제어됩니다. 알려진 키 집합 만 수락하십시오. 그렇지 않으면 404가 만족할 것이라고 생각합니다. – Ellead
나는 이것이 옳다고 생각하지 않는다. API는 HATEOAS를 중심으로 설계되어야합니다. 즉, 루트 URI의 응답 ("bookmarking"해야하는 유일한 URI)은 주어진 사용자가 액세스 할 수없는 URI에 대한 링크를 제공하지 않습니다. 관리자로 로그인하면 특정 사용자로 로그인 한 사용자와 API가 리턴 한 링크가 완전히 다릅니다. 인증되지 않은 사용자는 공개 URI 만 볼 수 있습니다. IMO 이러한 URI는 가시성이 아니라 자원 계층 구조 만 설명해야합니다. 특정 리소스 나 피드에 대한 액세스 권한을 가진 사람은 모두 동일한 URI를 가져야합니다. –
그리고 "should"는 RESTful 서비스를 만들고 북마크 된 "루트"URI보다 URI가 아닌 링크 관계에만 의존하는 검색/견고성 이점을 얻으려는 경우에만 의미합니다.HATEOAS를 사용하지 않는다면 REST를하지 않을 것입니다. HTTP API 만 있으면됩니다. 그런 혜택을 필요로하지 않고 그 일을하고 싶지 않다면 괜찮습니다. –