Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Is it possible to change the application's default API_KEY and MASTER_KEY with parse server? #3390

Closed
MateusCarvalho opened this issue Jan 18, 2017 · 3 comments

Comments

@MateusCarvalho
Copy link

I'm trying to change the default app_id and master_key that the parse gave me, for one's own, is it possible?

@flovilmart
Copy link
Contributor

You can set any value you want on your server, just make sure your clients use the same values.

@MateusCarvalho
Copy link
Author

MateusCarvalho commented Jan 18, 2017

@flovilmart And in Default API Parse is it possible? They tried to hack my app, they deleted some data, but I was able to recover a backup. I believe they are in possession of APP_ID yet.

@natanrolnik
Copy link
Contributor

natanrolnik commented Jan 18, 2017

@MateusCarvalho in Parse.com you can't, but I wouldn't bother, considering that it will stop working in 10 days. In your own Parse Server, you can set whatever keys you prefer.

The appId and keys (besides the master key) are not a security mechanism. It's not hard to sniff and get access to the HTTP calls your mobile/web app do, and extract the appId, clientKey, javascriptKey. It was even discussed to get rid of client keys at all, as they give a misleading sensation of security.

The real way of fixing this breach is reading the security section in the guides, understanding the two leves of security that Parse Server provides:

1 - CLPs - Class Level Permissions: Defines if a class and its objects can be public added, created, deleted or changed, or not. If not, all these operations will require the master key. Otherwise, ACLs apply:

2 - ACLs - Access Level Control: Defines if an object may be read or updated by specific users or roles.

They might be a bit confusing, a these are 2 different security layers; so take care not to adding both and avoiding users who actually should be able to access data to do so.

I won't get much deeper here, as it's better explained in the docs, linked above.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants