Protect Your API Key: Important Table Sharing Feedback | Clay

Protect Your API Key: Important Table Sharing Feedback

Feedback/Recommended change: When you share a table with someone, any HTTP API columns that you have that also contain an API key will be shared too allowing people to access your API key and see what it is. I can't think of any specific way to get around this since they are usually custom headers but just a heads up since it's an issue I've bumped into a few times.

5 comments

Mark L.
·
·
Seb, thanks for this. Good feedback. I can see the advantage of a "plug and play" experience if you're e.g. sharing a table with an internal teammate, for example. But we could improve the guardrails for situations where you're sharing more broadly. Best option for now would be to supply dummy values ("KEY_GOES_HERE") prior to sharing, but clearly we could make this better. Regardless, I'll pass this along internally. I know there's been some attention to developing role-based access controls lately. I think that work could lay the ground for better controls around this, too.
Seb H.
·
·
I think it is quite difficult since all of the headers are custom and some might be required for the exact function that you want to perform with the API call. The only potential and systematic thing I could think of as a fix would be adding a preset for authorisation - similar to what Postman has. Then you would select from a dropdown the type of authentication (e.g., API Key, OAuth 2.0, Bearer Token, Basic Authentication, JWT). From this, you could easily hide the value automatically whenever the table is shared. I know it is a simple fix to put something like ("KEY_GOES_HERE") prior to sharing but it's often something that just goes over your head as I have forgotten to numerous times along with many people who have shared their table with me.
Mark L.
·
·
Totally understand – we need to reduce that extra overhead of "Hmm, is this table completely good to share right now?" I don't know what a future solution would look like, but I think that type of approach would do very well. Set once securely, include them (or not) appropriately and programmatically.
Channeled
APP
·
·
Hi Seb H.! This thread was recently closed by our Support team. If you have a moment, please share your feedback:
Channeled
APP
·
·
Thank you so much for sharing your feedback Seb H.!