Tweeted twitter.com/#!/StackSecurity/status/484520660027572224
5 added 4 characters in body
source | link

Ok so consider the scenario in which you have two projects, one is a RESTful API, and the other is a public facing website.

The API uses cookie/token based authentication, and contains all of the logic of your application.

The website is built using a client-side MV* technology, what it can and cannot do is based on the role of the user authenticated by the API.

Hosting the HTML/JS/CSS of the website without introducing a third MVC framework is faster (and cheaper).

For example, you can have your RESTful API (maybe built with Django), and a server serving up HTML/JS/CSS as-is (let's say it's Apache), oror a RESTful API and have the website itself using a server side MVC technology (such as .net MVC) which restricts access to the HTML/CSS/JS based on the user role provided by the API.

This will slow things down, but is it more secure? Is it worth the overhead to not allow somebody traversing through your publically available client side code to not be able to see how your admin pages look and what API endpoints they call and how they call them, or is this security through obscurity?

Surely a determined attacker could figure this out anyway by using a tool like fiddler while browsing your public pages and then analyse your API with another tool?

Thanks

Ok so consider the scenario in which you have two projects, one is a RESTful API, and the other is a public facing website.

The API uses cookie/token based authentication, and contains all of the logic of your application.

The website is built using a client-side MV* technology, what it can and cannot do is based on the role of the user authenticated by the API.

Hosting the HTML/JS/CSS of the website without introducing a third MVC framework is faster (and cheaper).

For example, you can have your RESTful API (maybe built with Django), and a server serving up HTML/JS/CSS as-is (let's say it's Apache), or a RESTful API and have the website itself using a server side MVC technology (such as .net MVC) which restricts access to the HTML/CSS/JS based on the user role provided by the API.

This will slow things down, but is it more secure? Is it worth the overhead to not allow somebody traversing through your publically available client side code to not be able to see how your admin pages look and what API endpoints they call and how they call them, or is this security through obscurity?

Surely a determined attacker could figure this out anyway by using a tool like fiddler while browsing your public pages and then analyse your API with another tool?

Thanks

Ok so consider the scenario in which you have two projects, one is a RESTful API, and the other is a public facing website.

The API uses cookie/token based authentication, and contains all of the logic of your application.

The website is built using a client-side MV* technology, what it can and cannot do is based on the role of the user authenticated by the API.

Hosting the HTML/JS/CSS of the website without introducing a third MVC framework is faster (and cheaper).

For example, you can have your RESTful API (maybe built with Django), and a server serving up HTML/JS/CSS as-is (let's say it's Apache), or a RESTful API and have the website itself using a server side MVC technology (such as .net MVC) which restricts access to the HTML/CSS/JS based on the user role provided by the API.

This will slow things down, but is it more secure? Is it worth the overhead to not allow somebody traversing through your publically available client side code to not be able to see how your admin pages look and what API endpoints they call and how they call them, or is this security through obscurity?

Surely a determined attacker could figure this out anyway by using a tool like fiddler while browsing your public pages and then analyse your API with another tool?

Thanks

4 deleted 10 characters in body
source | link

Ok so consider the scenario in which you have two projects, one is a RESTful API, and the other is a public facing website.

The API uses cookie/token based authentication, and contains all of the logic of your web based application.

The website is built using a client-side MV* technology, what it can and cannot do is based on the role of the user authenticated by the API.

Hosting the HTML/JS/CSS of the website without introducing a third MVC framework is faster (and cheaper).

For example, you can have your RESTful API (maybe built with Django), and a server serving up HTML/JS/CSS as-is (let's say it's Apache), or a RESTful API and have the website itself using a server side MVC technology (such as .net MVC) which restricts access to the HTML/CSS/JS based on the user role provided by the API.

This will slow things down, but is it more secure? Is it worth the overhead to not allow somebody traversing through your publically available client side code to not be able to see how your admin pages look and what API endpoints they call and how they call them, or is this security through obscurity?

Surely a determined attacker could figure this out anyway by using a tool like fiddler while browsing your public pages and then analyse your API with another tool?

Thanks

Ok so consider the scenario in which you have two projects, one is a RESTful API, and the other is a public facing website.

The API uses cookie/token based authentication, and contains all of the logic of your web based application.

The website is built using a client-side MV* technology, what it can and cannot do is based on the role of the user authenticated by the API.

Hosting the HTML/JS/CSS of the website without introducing a third MVC framework is faster (and cheaper).

For example, you can have your RESTful API (maybe built with Django), and a server serving up HTML/JS/CSS as-is (let's say it's Apache), or a RESTful API and have the website itself using a server side MVC technology (such as .net MVC) which restricts access to the HTML/CSS/JS based on the user role provided by the API.

This will slow things down, but is it more secure? Is it worth the overhead to not allow somebody traversing through your publically available client side code to not be able to see how your admin pages look and what API endpoints they call and how they call them, or is this security through obscurity?

Surely a determined could figure this out anyway by using a tool like fiddler while browsing your public pages and then analyse your API with another tool?

Thanks

Ok so consider the scenario in which you have two projects, one is a RESTful API, and the other is a public facing website.

The API uses cookie/token based authentication, and contains all of the logic of your application.

The website is built using a client-side MV* technology, what it can and cannot do is based on the role of the user authenticated by the API.

Hosting the HTML/JS/CSS of the website without introducing a third MVC framework is faster (and cheaper).

For example, you can have your RESTful API (maybe built with Django), and a server serving up HTML/JS/CSS as-is (let's say it's Apache), or a RESTful API and have the website itself using a server side MVC technology (such as .net MVC) which restricts access to the HTML/CSS/JS based on the user role provided by the API.

This will slow things down, but is it more secure? Is it worth the overhead to not allow somebody traversing through your publically available client side code to not be able to see how your admin pages look and what API endpoints they call and how they call them, or is this security through obscurity?

Surely a determined attacker could figure this out anyway by using a tool like fiddler while browsing your public pages and then analyse your API with another tool?

Thanks

3 edited title
source | link

Is letting just anybody see the appearance/html/javascript of your admin pages a security risk?

Ok so consider the scenario in which you have two projects, one is a RESTful API, and the other is a public facing website.

The API uses cookie/token based authentication, and contains all of the logic of your web based application.

The website is built using a client-side MV* technology, what it can and cannot do is based on the role of the user authenticated by the API.

Hosting the HTML/JS/CSS of the website without introducing a third MVC framework is faster (and cheaper).

For example, you can have your RESTful API (maybe built with Django), and a server serving up HTML/JS/CSS as-is (let's say it's Apache), or a RESTful API and have the website itself using a server side MVC technology (such as .net MVC) which restricts access to the HTML/CSS/JS based on the user role provided by the API.

This will slow things down, but is it more secure? Is it worth the overhead to not allow somebody traversing through your publically available client side code to not be able to see how your admin pages look and what API endpoints they call and how they call them, or is this security through obscurity?

Surely a determined could figure this out anyway by using a tool like fiddler while browsing your public pages and then analyse your API with another tool?

Thanks

Is letting just anybody see the appearance/html of your admin pages a security risk?

Ok so consider the scenario in which you have two projects, one is a RESTful API, and the other is a public facing website.

The API uses cookie/token based authentication, and contains all of the logic of your web based application.

The website is built using a client-side MV* technology, what it can and cannot do is based on the role of the user authenticated by the API.

Hosting the HTML/JS/CSS of the website without introducing a third MVC framework is faster.

For example, you can have your RESTful API (maybe built with Django), and a server serving up HTML/JS/CSS as-is (let's say it's Apache), or a RESTful API and have the website itself using a server side MVC technology (such as .net MVC) which restricts access to the HTML/CSS/JS based on the user role provided by the API.

This will slow things down, but is it more secure? Is it worth the overhead to not allow somebody traversing through your publically available client side code to not be able to see how your admin pages look and what API endpoints they call and how they call them, or is this security through obscurity?

Surely a determined could figure this out anyway by using a tool like fiddler while browsing your public pages and then analyse your API with another tool?

Thanks

Is letting just anybody see the appearance/html/javascript of your admin pages a security risk?

Ok so consider the scenario in which you have two projects, one is a RESTful API, and the other is a public facing website.

The API uses cookie/token based authentication, and contains all of the logic of your web based application.

The website is built using a client-side MV* technology, what it can and cannot do is based on the role of the user authenticated by the API.

Hosting the HTML/JS/CSS of the website without introducing a third MVC framework is faster (and cheaper).

For example, you can have your RESTful API (maybe built with Django), and a server serving up HTML/JS/CSS as-is (let's say it's Apache), or a RESTful API and have the website itself using a server side MVC technology (such as .net MVC) which restricts access to the HTML/CSS/JS based on the user role provided by the API.

This will slow things down, but is it more secure? Is it worth the overhead to not allow somebody traversing through your publically available client side code to not be able to see how your admin pages look and what API endpoints they call and how they call them, or is this security through obscurity?

Surely a determined could figure this out anyway by using a tool like fiddler while browsing your public pages and then analyse your API with another tool?

Thanks

2 added 160 characters in body
source | link
1
source | link