What is the issue?
Currently, if we are using GitHub, we have to hard-code clientSecret
in our js/html files, which has potential risks.
There are already some discussions about that:
In brief, hard-coding clientSecret
will cause some security concerns.
Does it really matter?
Yes but no.
Impersonate you website?
Attackers may copy your clientId
and clientSecret
, but the platform will check the redirect_uri
as well.
That means that, attackers can't mislead users to their fake sites with your clientId
(unless something like DNS hijacking, which might be another story), so they can't get user's code
on their sites with your clientSecret
.
In addition, it's more convenient for "attackers" to create a new OAuth App than copy yours, and the target of the "attackers" is the platform but not your website.
From another perspective, your website is "static" and have nothing worth to be attacked...
So you don't need to worry about that.
Impersonate you OAuth App?
Github: OAuth Authorizations API - for example, if attackers get your client secret, they can revoke a grant of an user, so the user have to authorize your app again when he try to login on your website next time. It's possible if someone is aiming at your website, but it might not be so critical.
In brief, it does have security concerns, but not critical. This is why gitment and gitalk didn't fix that.
Plans of enhancement
But it's still an issue.
Currently:
clientSecret
is only used for getting access_token
- The API endpoint for getting
access_token
does not support CORS, so we have to use proxy for now
To completely solve this issue, you can use a private proxy to get access_token
, and store your clientSecret
in the proxy, rather than in your client code.
An existing project is https://github.com/prose/gatekeeper, which can be deployed on Heroku/Azure by yourself easily. But it's not compatible with our current proxy option
So Vssue is planning to: