all 11 comments

[–][deleted] 3 insightful - 2 fun3 insightful - 1 fun4 insightful - 2 fun -  (8 children)

they are just metadata that can be read by the server to determine whether you want to grant the request

sec-fetch-dest: document, the destination of the request is a document

sec-fetch-mode: navigate, the request is being made by a user navigating HTML pages

sec-fetch-site: cross site, the request is coming from a different location than the server hosting the resource

You can read more here

[–]chickenz[S] 3 insightful - 2 fun3 insightful - 1 fun4 insightful - 2 fun -  (7 children)

i just cant imagine why i would want to process such things...

in a normal transaction:

1) a browser will try to access my server by going to my webpage/site..

2) i read the "GET" or "POST" request, which includes the page that is requested..

3) i dynamically generate the html and return it.

i have read the documentation about the sec- stuff, and i just dont think that i want to even pay any attention to those header variables.

this is one of the basic advantages to writing a custom web server... i dont need to worry about some weird configuration bullshit that might produce some unexpected result.. i just ignore such things and everything is hardcoded into my server.


[–][deleted] 3 insightful - 2 fun3 insightful - 1 fun4 insightful - 2 fun -  (6 children)

The idea is that if you really needed to, you can make your site more secure from certain attacks by allowing only the specific requests you are expecting

[–]chickenz[S] 3 insightful - 2 fun3 insightful - 1 fun4 insightful - 2 fun -  (5 children)

ok, i am trying to follow you on this...

but if i get a "GET /file.ext HTTP/1.1", and i respond by returning the html for that page request, can you describe for me a situation where i would not want to process that request?

i think that i just want my webserver to ignore the cors stuff... i cant imagine why it would make a difference to me either way.

[–][deleted] 2 insightful - 2 fun2 insightful - 1 fun3 insightful - 2 fun -  (4 children)

I personally have never filtered on any of those flags, nor can I think of a reason why you would want to deny a request like that based on them, but I am hardly a security expert.

[–]chickenz[S] 2 insightful - 2 fun2 insightful - 1 fun3 insightful - 2 fun -  (3 children)

I almost suspect that all of this "cross site" stuff is somehow a not so well documented system that allows the googles and facebooks to "track" our internet viewing trail, but I could be wrong about this.

In the end, I really don't care because I am going to have my server ignore that nonsense anyways.

This is a noticeable advantage to using a custom server as opposed to using an off the shelf server such as being or apache.

All that I am really interested in is the GET or POST request and I want to read and set cookies.

..and of course, I want to handle the detection of and handling of DDOS nonsense. I have a few ideas regarding how to handle this WITHOUT using that cloudflare crap.

[–][deleted] 2 insightful - 2 fun2 insightful - 1 fun3 insightful - 2 fun -  (2 children)

You will probably want to set some CORS flags to set which methods and headers are allowed. There are many situations that you might want to restrict the requests to GET or POST

[–]chickenz[S] 2 insightful - 1 fun2 insightful - 0 fun3 insightful - 1 fun -  (1 child)

My code does that just fine .

When I read the http request, I only respond to GET or POST requests.

If the request is a POST request, I will look for a "Content-Length:" http request field, which will contain an integer value which can be used to verify that I have actually received the correct number of POST data characters.

And, I might want to keep track of cookies.

[–][deleted] 3 insightful - 2 fun3 insightful - 1 fun4 insightful - 2 fun -  (0 children)

Sounds like you already have the CORS handled then

For cookies you wanna set the 'secure' and 'http-only' flags. You also want to use a key to cryptographically sign any of the cookies so you know you attached them and not an attacker. HMAC is considered the best practices protocol for key generation

[–]Vulptex 2 insightful - 2 fun2 insightful - 1 fun3 insightful - 2 fun -  (0 children)

Of course someone posts about this when I'm doing it. Totally just YET ANOTHER coincidence!