So I am currently working on the API of an application that will be serving many users. Currently the only "sensitive" information being stored using the API is user emails and names. The application allows users to form teams (which can be private). The API serves requests coming from Slack and also from a client website. Metadata about user communications on slack is also collected by the API.

Assuming no secrets are exposed in the codebase, would it be ok to keep the repo public?

The main arguments for making it public are:

  1. Keep the project open source.
  2. It can be a useful GraphQL learning resource.
  3. Access to workflow tools that are only free for open source projects.
  4. Get community help on finding and patching exploits.

The main arguments against making it public are:

  1. If there is something we missed or forgot to secure it could be exploited.
  2. People would figure out how it works internally and maybe try to mess with things that arent thoroughly validated yet.
  3. If we are ever careless and accidentally commit something sub-par that could create problems too.

What's the best approach here? Thanks for any help.

  • This is basically the same question for any web app. Feb 13, 2018 at 4:39

1 Answer 1


I think you are okay making this a public repo as long as the following conditions are met:

  1. No application secrets such as keys or certificates are maintained in the repo.
  2. No sensitive or personal identifying information, such as user names, email addresses, passwords, etc. are maintained in the repo.
  3. No algorithms that if reverse engineered could lead to the exposure or exfiltration of any of the above in the runtime system. For example, reverse engineering an encryption routine or a protocol that could expose a user name and password.

Assuming these are met one important factor that shouldn't be overlooked is ensuring that your app is architected to protect itself from intrusion. This would include user authentication, ensuring that the front-end only communicates to the backend through the API (i.e. no direct use of backend services like making a db call from the frontend), using secure protocols (like HTTPS) to protect the communications channel, and ensuring that the OS and any other services you are using are regularly up-to-date on security patches.

  • See shannon's maxim. If the application relies on the secrecy of an encryption routine or protocol for security, it is broken from the start.
    – forest
    Feb 12, 2018 at 2:39

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .