2

I'm using Heroku to host a small number of services. I want to better understand the access permissions on the files that I'm putting onto my Heroku instances.

First off, I am aware that I am handing my data over to an external company, and that it's game over if bad actors manage to infiltrate Heroku or to hack my individual user account.

With that out of the way, I have a few questions:

  • How secure is the source code of the microservices that I'm pushing to a Heroku dyno? If someone else knows the URL of my app, e.g. https://newbs-dyno.herokuapp.com, what can they do? Can unauthorized users clone the underlying git repo? Can they view the contents (files and folders) that I've put on the dyno?

  • How securely stored are the configuration variables? I want to use config vars to store some credentials, as described in the documentation. Is this good practice?

What defines how visible or invisible my dyno's contents, configuration variables included, are? Is it correct to think of my dyno as a server-side application that exposes a few well-defined endpoints?

Improve this question

1 Answer 1

Reset to default
2

Heroku is a platform as a service offering, your code will live in virtual containers, this means that it is better isolated from other containers running in the same server (speaking strictly about direct file access).

The way to store secrets, as you pointed out, is to use config vars. The heroku documentation specifies this as the secure way:

A better solution is to use environment variables, and keep the keys out of the code. On a traditional host or working locally you can set environment vars in your bashrc file. On Heroku, you use config vars.

You can in fact keep files outside of the public folder by specifying the Document Root of your application. This will set the folder where the web server will look for your php files. The web server will reject direct internet access to files outside of the Document Root, your code may still introduce vulnerabilities that allow this but from a configuration point of view this is the way to go.

Improve this answer

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.