Regarding the document of Pyramid framework, they description how to user http_cache parameter.
However, this document doesn't explain the default action if user doesn't set this parameter.
The default action mean browser will cache the response or not cache the response or base on the behavior for each browser
So, could you please share this case to me?
Thank you.
First, if your web server supports it, you can configure your web server to set Expires and Cache-Control response headers. Your web server's documentation should explain how it interacts with CGI scripts and web frameworks that also may set these headers.
Second, when you set the http_cache argument in Pyramid, then you can set Expires and Cache-Control response headers depending on the values in the argument. If you omit this argument, then Pyramid does nothing in this regard.
Finally web browsers may have their own caching mechanism.
This article, Caching Tutorial for Web Authors and Webmasters, is an excellent and thorough discussion on the matter.
Related
I am looking to run an express.js app in production, and the last thing I want is for anyone to know that it is powered by express.js or node in general. I read this article:
https://expressjs.com/en/advanced/best-practice-security.html
and know for certain I need to remove the X-Powered-By (whether I use Helmet or not).
What bothers me is the statement in the article that says:
Note: Disabling the X-Powered-By header does not prevent a
sophisticated attacker from determining that an app is running
Express. It may discourage a casual exploit, but there are other ways
to determine an app is running Express.
What other ways can an attacker detect an express.js app running and how can I protect against this?
This comment might interest you. I've copy-pasted the points below:
Common methods to detect if a server is running Express
Are there response headers all in lower-case? The more there are, the more points assigned as likely being Node.js server, which in turn counts towards Express.js.
Some requests to random URLs are made looking for a 404. If the response body is in the format "Cannot GET {url}" then it gives a massive number of points towards it being Express.js. This is actually the main give away it uses to know you are an Express.js server.
What does the ETag header look like if there is one? There are definitions for the different versions of the ETag header format for Express.js, so this header matching certain formats not only gives points towards being Express.js, but even hints at the version of Express.js you are using, since the format has changed over time (even the X-Powered-By header doesn't provide that level of detail, since it does not contain a version).
As explained on the official website, there are many things to do :
Here is the main extract, the full list of recommandations is on the link I gave you.
Use Helmet
var helmet = require('helmet')
app.use(helmet())
At a minimum, disable X-Powered-By header
app.disable('x-powered-by')
I have a web application that requires an offline option.
I have built an offline form in an HTML page that lives on local machines and writes to localStorage.
The offline app uses an eventListener to determine when there is an internet connection and then sends the data in localStorage to the web application over JSON (xmlHttpRequest).
The problem is that the request is cross-domain (from the personal computer's drive to the web application), so it returns "No 'Access-Control-Allow-Origin' header is present on the requested resource. Origin 'null' is therefore not allowed access."
I've investigated using CORS and it seems like it would work for this as long as I set the Access-Control-Allow-Origin parameter to "*".
Are there any other options for uploading localStorage data to a web server from a personal computer?
Looking forward to hearing suggestions. Please don't hesitate to request further details if necessary.
Thanks, Noah
I solved this problem by adding the following header to the page in my web application that is responsible for processing the JSON data.
Response.AddHeader "Access-Control-Allow-Origin","*"
I recognize that this opens up the application to all origins and that this can pose a security risk, but I have implemented a token to ensure that data only comes from the offline version of the app. Also, there was no alternative because all the requests will come from file://, not other domains that could be cataloged.
Hope this helps someone! Cheers, N
The x-requested-with header is kind of confusing to me. I know it can be used to defend against CSRF attacks, and that it is used to identify Ajax calls...but what is it really?
It just tells you what the request was...requested with?
Could there ever be a reasonable situation in which the header is present but set to some value other than "XMLHttpRequest"? I would imagine so, but I've never seen it set to anything else.
Just like the User-Agent header, it is provided by the client and can contain literally anything.
It is not at all reliable for any server-side security check.
Android sets X-Requested-With to the package ID of the app, for third-party apps that use the WebView component to embed a browser into their UI.
Presumably this could be used for debugging and/or statistics, but the values cannot be trusted because it would be possible for an attacker to write a custom client that sets it to anything just to try to break your server.
Do you know how to change the response header in CouchDB? Now it has Cache-control: must-revalidate; and I want to change it to no-cache.
I do not see any way to configure CouchDB's cache header behavior in its configuration documentation for general (built-in) API calls. Since this is not a typical need, lack of configuration for this does not surprise me.
Likewise, last I tried even show and list functions (which do give custom developer-provided functions some control over headers) do not really leave the cache headers under developer control either.
However, if you are hosting your CouchDB instance behind a reverse proxy like nginx, you could probably override the headers at that level. Another option would be to add the usual "cache busting" hack of adding a random query parameter in the code accessing your server. This is sometimes necessary in the case of broken client cache implementations but is not typical.
But taking a step back: why do you want to make responses no-cache instead of must-revalidate? I could see perhaps occasionally wanting to override in the other direction, letting clients cache documents for a little while without having to revalidate. Not letting clients cache at all seems a little curious to me, since the built-in CouchDB behavior using revalidated Etags should not yield any incorrect data unless the client is broken.
as far as i know 'Access-Control-Allow-Origin' is used as part of CORS to limit which all hosts can request data from a given api server. This flag/variable value is set by the server as part of a response.
I did happen to stumble upon this chrome extension which says:
Allow to you request any site with ajax from any source. Add to
response - 'Access-Control-Allow-Origin: *' header
Developer tool.
Summary Add to response header rule - 'Allow-Control-Allow-Origin: *'
Hint Same behavior you can get just using chrome flags [http://www.chromium.org/developers/how-tos/run-chromium-with-flags]
chrome --disable-web-security
or
--allow-file-access-from-files --allow-file-access --allow-cross-origin-auth-prompt
so that means from the client side I can change the response header. So it means that if i set on server : 'Access-Control-Allow-Origin : http://api.example.com' this setting can be overwritten by client 'Access-Control-Allow-Origin : *'. or may be I do not want to support cors - so i dont set it, but this will still show as if I do support CORS.
If that is the case, what is the point in having my server side setting?? isn't that left redundant??
May be I am being too naive here, and not getting the basics of it.
CORS is a security feature to protect clients from CORF, or Cross Origin Request Forgery. It is not intended to secure servers, as a client can simply choose to ignore them.
An example of CORF would be visiting a website, and client-side code on that website interacts with another website on your behalf, do things like submitting data to a website, or reading data that requires authentication as you, all with your active authentication sessions.
Theoretically, without CORS, it would be possible to create a website that will fetch your email from a webmail provider (provided you are logged in at the time), and post it back to a server for malicious individuals to read.
To avoid this, you shouldn't browse the web with such security features disabled. It's available to ease development, not for general browsing.