How to Restrict JSON Access

Restrict JSON access only one use

Assuming you are using that GeoIP JSON capability from dynamic pages, you can add a random identifier, with something such as:

$id = md5(random());

Then save that $id in a session table and send it along the HTML.

Change your jQuery script to include that identifier when the GeoIP request is sent to the server. On the server, you first check whether the $id sent by the jQuery exists in your session table. If not, then stop right there, and if you'd like, add the IP address to your firewall for a while that way you waste nearly no resources.

The $id must be deleted after one use if you do not want to allow more than one use. That way even your page will not receive a GeoIP in return.

You should use a similar session identifier for any form you use on your website. It is also possible to attach such to a cookie, but in Europe, they are big at asking people for not using cookies... so you may not want to do that anyway.

How to restrict json files that are stored under wwwroot folder to view from Web Browser

Based on your last comment above:

It's perfectly acceptable to store css and javascript files in wwwroot. However, do not store anything secret there. Storing secrets like connectionstrings are best in EnvironmentVariables.

Block users from accessing JSON files from url : Drupal 7

Above code works fine. I made a mistake of not adding "package" pretext for json files.
So code in .htaccess should be:

<FilesMatch "\.(engine|inc|info|install|make|module|profile|test|po|sh|.*sql|theme|tpl(\.php)?|xtmpl)(~|\.sw[op]|\.bak|\.orig|\.save)?$|^(\.(?!well-known).*|Entries.*|Repository|Root|Tag|Template|composer|package\.(json|lock)|web\.config)$|^#.*#$|\.php(~|\.sw[op]|\.bak|\.orig\.save)$">
    Order allow,deny
</FilesMatch>

restrict browsing to some resources

You can't block a resource from client access if it needs to be accessed from the client (using JavaScript). So, what you are asking is not really possible without restricting all client access (eg. user/password authentication), but then any authenticated users can still access these files.

You could prevent "casual" direct access by customising the client-side request with a custom HTTP request header and check for this header in .htaccess and block otherwise. However, this depends on how these files are currently being called as it will require an update to your JS code.

For example, when requesting package.json or configuration.json you also send an HTTP request header like X-Custom-Header: some-value.

In .htaccess you can block requests that don't have this header (or it is not the correct value). For example:

RewriteCond %{HTTP:X-Custom-Header} !^some-value$
RewriteRule (^|/)(package|configuration)\.json$ - [F]

This only prevents casual direct access, ie. someone types the URL directly into the browser address bar. Since the file is still downloaded to the browser, the user can still read the file in the browser (dev tools). The header can also be easily faked if someone is so inclined. So, this doesn't provide any real security.

Instead of sending a custom HTTP request header, you could perhaps check the Referer header (if this is being set for such requests). However, this is less reliable as the browser can be configured not to send the Referer header. And again, this is easily faked.

---

Related Topics