So this is only if you don't have your own server and you want to connect to a 3rd party API client to server?
These are all server features, you didn't actually secure any API keys at all. You just used another api key to a service which also enforces throttling & whitelisting domains... Now you've replicated the original problem, the key is visible.
Most servers can throttle requests & send server to server api calls (not able to be intercepted) on behalf of their client as a minimum requirement.
This is essentially a simple ExpressJS middleware or perhaps an Nginx Only solution that you seem to be selling as a service?
Is there any indication this article is an advertisement?
The author's username is KOR Connect... so yeah you are totally right. This is an advertisement. And as you mentioned it does not even solve the problem. It just replicates the problem.
This article is not meant to be an advertisement, it is meant to walk users through the steps of using KOR Connect and is meant to serve as a quicker alternate way of integrating 3rd party APIs.
You do have a valid point, we don’t want this to seem like an advertisement, we use this organization channel so that more than one team member can contribute to each blog, would you suggest we use individual accounts? We are very new to using Dev.to, and would love to hear some feedback.
To address the replication of the problem, as mentioned above:
Yes, if you have your own server you can implement this through your backend. However KOR Connect is meant for services hosted on a CDN that don’t require servers, allowing these developers the ability to connect to 3rd party APIs, as well as a place to secure the 3rd party API keys without having to setup or maintain a backend.
Furthermore, The public key provided is to identify the user's project within KOR Connect. Having access to this public key doesn't grant you access to the specific API you are using or to your API's key,
There is no secret being exposed; the API Key that is provided by KOR Connect is meant for identifying users' projects and the usage of the service, as well as troubleshooting when developers run into issues. Having access to this public key doesn't grant you access to the specific API you are using or to your API's key. The public URL that is provided by KOR Connect has a number of security layers implemented when it is being called to reduce the likelihood of malicious activity making it through to the integrating API, preventing automated attacks, and disruptions of service.
KOR Connect, as stated by the article, is meant to integrate APIs that are for public facing websites/ applications that don’t require user authentication. Financial applications would require some kind of user auth before allowing access to sensitive information which KOR Connect does not currently offer.
The KOR api key IS a secret, any secret that lets you leverage other secrets is transitively a secret. And its exposed, no matter how good this fraud detection is..unless its leveraging the equivalent of client certificates it can be hacked. You can never really know the client, you can NOT track ips cause botnets. You can NOT profile api requests you dont understand for maliciousness. And now kor has your secret..so youve opened you secret to an attack on kor.
Your wrong about financial institutions, they have app to app api keys all the time all it takes is one dev to use this product for that use case and boom..chaos
Im guessing youll delete this comment, but this is a flawed and dangerous product.
CORS is pretty tight. If the allowed origin is strictly from the host domain you're not going to have any problems with people poking around from postman.
Besides, the API you're connecting to should be secure in its own right if it's dealing with sensitive information lol. It's not up to a relay to protect data which is what this is, a weak bastion of sorts.
my curl/wget cares nothing about CORS. KOR is positioning positioning itself as a secure way to connect to http services requiring a secret by issuing a different KOR key and saying they'll detect miss-use. anyone can go to a site using KOR and see the KOR key, and curl the same request. it's a broken idea, and scary that there are tech folks out there such as yourself who don't understand it as such immediately
The purpose of KOR Connect is to allow users the ability to do backend tasks ( as of right now integrate 3rd party APIs) without a backend. So yes, KOR Connect is meant to allow developers to connect 3rd party APIs without having to build or maintain a server.
The API key that KOR Connect provides is a public API key similar to the ones that are provided by firebase, and is only used on KOR Cornnect’s end to identify each user’s project. The developers' 3rd party API keys are secured on a proxy within an AWS Lambda. The new secure URL that KOR Connect provides has a number of additional security features added to it to validate the origin of the call, limit exposure to automated attacks, as well as limiting call access (in the way of per-user and global rate limiters).
KOR Connect is meant to be a service that allows CDN/ static sites/ JAMStack/ single page applications, that don’t require servers, to continue not requiring any backend infrastructure, but allowing these developers the ability to connect to 3rd party APIs, as well as a place to secure the 3rd party API keys. To answer your question, yes, these are server features without a server, or in our case it's actually an infrastructure abstraction layer. The public key provided is to identify a users project, having access to this public key doesn't grant you access to the specific API you are using or to your API's key
This article is not meant to be an advertisement, it is meant to walk users through the steps of using KOR Connect. It is posted within the KOR Connect organization account, and is meant to serve as a quicker alternate way of integrating 3rd party APIs.
This article is written by a collaboration of team members from the KOR Connect company, as it states within the organization account. None of which is hidden.
We don’t want this to seem like an advertisement, we use this organization channel so that more than 1 team member can contribute to each blog, would you suggest we post using individual accounts? We are very new to using Dev.to, and would love to hear some feedback.
It would be great to hear your thoughts on this space. What have been the challenges you’ve faced when hosting without a server i.e CDN only? Have you tried hosting on a CDN in the past?
Well I'm a server engineer but I've worked with static CDN sites. There are several solutions for obfuscating keys including browsifying expressjs (etc). Many CDN's already offer a similar service to what you're selling.
Ideally, any third party services also have domain whitelists for the client api calls. So even though its a public key, they're useless elsewhere (even in postman), because it's paired to your domain. Centralizing all client API calls through a third party relay is a high risk, low reward situation with latency we cannot optimize and could possibly be intentionally latent depending on service level (how much is charged).
The only use case I see for this service would be to implement some server to server API in a web client, which you shouldn't have a need to do, esp on a static CDN site.
As for the other topic of my first comment and your comment about being new to Dev. Your article may have an author profile but it has no disclosure in the content. Typically ethics / law / regulation require a disclosure statement the bottom, identifying the connection the author(s) has/have with the product featured. It's very possible for anyone else to make an account with your company name. Make sure to put a disclosure at the bottom. Perhaps add some details about which authors contributed to this article and what their role in the company is.
When that stuff is not there, it seems dishonest and/or could be a fake article and/or advertisement (marketing content with no stated author).
I see your point of view. Being a server engineer you work with backends, servers, and cloud providers for a living so securing an API hosted by a CDN would not be a significant task for you. However, for many front-end specific engineers dealing with cloud providers can be a difficult task that requires a steep learning curve. To implement a secure connection via a CDN provider it often requires a combination of many components from the cloud provider. We are also aware that there are other ways of integrating 3rd party APIs and only want to provide an alternative that is quicker to use than other options. Furthermore, we are aware that there are different levels of security depending on the approach taken; KOR Connect provides different options for security levels depending on what the project is and the amount of security the connection requires.
If I understand you correctly when you said “Ideally, any third party services also have domain whitelists for the client api calls. So even though its a public key, they're useless elsewhere (even in postman), because it's paired to your domain.” So if you mean that the public API keys that are provided are not used for security but are paired with the domain, then that is how KOR Connect works also.
Reducing latency is very important for us, and we are constantly working to improve this. Once again, given your expertise, optimizing latency may not be as simple for all engineers. As far as KOR Connect throttling performance, we do not have plans to ever do this, but I can see your concerns surrounding this.
Regarding the disclosure of content; this article is published under the KOR Connect organization that requires the company Dev.to account to allow the publishing. The authors are also listed within the Organization page. We will be sure to list who contributed to articles in the future, and maybe publish content on a single account within the organization to prevent this issue in the future. Thank you and we appreciate this advice.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
So this is only if you don't have your own server and you want to connect to a 3rd party API client to server?
These are all server features, you didn't actually secure any API keys at all. You just used another api key to a service which also enforces throttling & whitelisting domains... Now you've replicated the original problem, the key is visible.
Most servers can throttle requests & send server to server api calls (not able to be intercepted) on behalf of their client as a minimum requirement.
This is essentially a simple ExpressJS middleware or perhaps an Nginx Only solution that you seem to be selling as a service?
Is there any indication this article is an advertisement?
Do you work for this company?
If so/not why isn't any of that mentioned above?
The author's username is KOR Connect... so yeah you are totally right. This is an advertisement. And as you mentioned it does not even solve the problem. It just replicates the problem.
This article is not meant to be an advertisement, it is meant to walk users through the steps of using KOR Connect and is meant to serve as a quicker alternate way of integrating 3rd party APIs.
You do have a valid point, we don’t want this to seem like an advertisement, we use this organization channel so that more than one team member can contribute to each blog, would you suggest we use individual accounts? We are very new to using Dev.to, and would love to hear some feedback.
To address the replication of the problem, as mentioned above:
Yes, if you have your own server you can implement this through your backend. However KOR Connect is meant for services hosted on a CDN that don’t require servers, allowing these developers the ability to connect to 3rd party APIs, as well as a place to secure the 3rd party API keys without having to setup or maintain a backend.
Furthermore, The public key provided is to identify the user's project within KOR Connect. Having access to this public key doesn't grant you access to the specific API you are using or to your API's key,
So scary that there are devs who wont see the problem with this use it and expose this “public” secret.
Could you imagine a financial app using this? Total chaos
There is no secret being exposed; the API Key that is provided by KOR Connect is meant for identifying users' projects and the usage of the service, as well as troubleshooting when developers run into issues. Having access to this public key doesn't grant you access to the specific API you are using or to your API's key. The public URL that is provided by KOR Connect has a number of security layers implemented when it is being called to reduce the likelihood of malicious activity making it through to the integrating API, preventing automated attacks, and disruptions of service.
KOR Connect, as stated by the article, is meant to integrate APIs that are for public facing websites/ applications that don’t require user authentication. Financial applications would require some kind of user auth before allowing access to sensitive information which KOR Connect does not currently offer.
The KOR api key IS a secret, any secret that lets you leverage other secrets is transitively a secret. And its exposed, no matter how good this fraud detection is..unless its leveraging the equivalent of client certificates it can be hacked. You can never really know the client, you can NOT track ips cause botnets. You can NOT profile api requests you dont understand for maliciousness. And now kor has your secret..so youve opened you secret to an attack on kor.
Your wrong about financial institutions, they have app to app api keys all the time all it takes is one dev to use this product for that use case and boom..chaos
Im guessing youll delete this comment, but this is a flawed and dangerous product.
CORS is pretty tight. If the allowed origin is strictly from the host domain you're not going to have any problems with people poking around from postman.
Besides, the API you're connecting to should be secure in its own right if it's dealing with sensitive information lol. It's not up to a relay to protect data which is what this is, a weak bastion of sorts.
my curl/wget cares nothing about CORS. KOR is positioning positioning itself as a secure way to connect to http services requiring a secret by issuing a different KOR key and saying they'll detect miss-use. anyone can go to a site using KOR and see the KOR key, and curl the same request. it's a broken idea, and scary that there are tech folks out there such as yourself who don't understand it as such immediately
Lol what?
A CORS protected middleware isn't a vulnerability.
The purpose of KOR Connect is to allow users the ability to do backend tasks ( as of right now integrate 3rd party APIs) without a backend. So yes, KOR Connect is meant to allow developers to connect 3rd party APIs without having to build or maintain a server.
The API key that KOR Connect provides is a public API key similar to the ones that are provided by firebase, and is only used on KOR Cornnect’s end to identify each user’s project. The developers' 3rd party API keys are secured on a proxy within an AWS Lambda. The new secure URL that KOR Connect provides has a number of additional security features added to it to validate the origin of the call, limit exposure to automated attacks, as well as limiting call access (in the way of per-user and global rate limiters).
KOR Connect is meant to be a service that allows CDN/ static sites/ JAMStack/ single page applications, that don’t require servers, to continue not requiring any backend infrastructure, but allowing these developers the ability to connect to 3rd party APIs, as well as a place to secure the 3rd party API keys. To answer your question, yes, these are server features without a server, or in our case it's actually an infrastructure abstraction layer. The public key provided is to identify a users project, having access to this public key doesn't grant you access to the specific API you are using or to your API's key
This article is not meant to be an advertisement, it is meant to walk users through the steps of using KOR Connect. It is posted within the KOR Connect organization account, and is meant to serve as a quicker alternate way of integrating 3rd party APIs.
This article is written by a collaboration of team members from the KOR Connect company, as it states within the organization account. None of which is hidden.
We don’t want this to seem like an advertisement, we use this organization channel so that more than 1 team member can contribute to each blog, would you suggest we post using individual accounts? We are very new to using Dev.to, and would love to hear some feedback.
It would be great to hear your thoughts on this space. What have been the challenges you’ve faced when hosting without a server i.e CDN only? Have you tried hosting on a CDN in the past?
Well I'm a server engineer but I've worked with static CDN sites. There are several solutions for obfuscating keys including browsifying expressjs (etc). Many CDN's already offer a similar service to what you're selling.
Ideally, any third party services also have domain whitelists for the client api calls. So even though its a public key, they're useless elsewhere (even in postman), because it's paired to your domain. Centralizing all client API calls through a third party relay is a high risk, low reward situation with latency we cannot optimize and could possibly be intentionally latent depending on service level (how much is charged).
The only use case I see for this service would be to implement some server to server API in a web client, which you shouldn't have a need to do, esp on a static CDN site.
As for the other topic of my first comment and your comment about being new to Dev. Your article may have an author profile but it has no disclosure in the content. Typically ethics / law / regulation require a disclosure statement the bottom, identifying the connection the author(s) has/have with the product featured. It's very possible for anyone else to make an account with your company name. Make sure to put a disclosure at the bottom. Perhaps add some details about which authors contributed to this article and what their role in the company is.
When that stuff is not there, it seems dishonest and/or could be a fake article and/or advertisement (marketing content with no stated author).
Lol.
Jesus Christ dude.
Hi Jeremy,
I see your point of view. Being a server engineer you work with backends, servers, and cloud providers for a living so securing an API hosted by a CDN would not be a significant task for you. However, for many front-end specific engineers dealing with cloud providers can be a difficult task that requires a steep learning curve. To implement a secure connection via a CDN provider it often requires a combination of many components from the cloud provider. We are also aware that there are other ways of integrating 3rd party APIs and only want to provide an alternative that is quicker to use than other options. Furthermore, we are aware that there are different levels of security depending on the approach taken; KOR Connect provides different options for security levels depending on what the project is and the amount of security the connection requires.
If I understand you correctly when you said “Ideally, any third party services also have domain whitelists for the client api calls. So even though its a public key, they're useless elsewhere (even in postman), because it's paired to your domain.” So if you mean that the public API keys that are provided are not used for security but are paired with the domain, then that is how KOR Connect works also.
Reducing latency is very important for us, and we are constantly working to improve this. Once again, given your expertise, optimizing latency may not be as simple for all engineers. As far as KOR Connect throttling performance, we do not have plans to ever do this, but I can see your concerns surrounding this.
Regarding the disclosure of content; this article is published under the KOR Connect organization that requires the company Dev.to account to allow the publishing. The authors are also listed within the Organization page. We will be sure to list who contributed to articles in the future, and maybe publish content on a single account within the organization to prevent this issue in the future. Thank you and we appreciate this advice.