I am sorry but this question needs to be long so you can understand the problem and it is absolutely relative the size of my problem, I am seeking web security experts opinion so thank you for your time in advance.
I) CONTEXT
My problem in the same context of Google Analytics, the main goal is to collect data from front end but I have no access to the front end, and there's a JavaScript script loaded from a remote server to the front end by adding in the front end by my clients (like Google Analytics). This script posts data to an API but put in mind that there is no authentication process on the front end( Imagine the front end as a tutorial web page for example). My goal is to secure these post requests, but I've encountered a challenge.
The issue is that HTTP-only cookies (HTTP-only docs ), which are typically used for authentication and security, require an initial authentication process to set the cookies for a token for example. This means that the data and tokens I want to secure may still be visible on the client side before any authentication takes place. This is a significant vulnerability because it means that anyone with access to the front end, including potential attackers, can see and potentially exploit this data.
The fact that I have no control over the front end makes it even more challenging to implement security measures, such as authentication or authorization, on the client side.
II) WHAT HAVE BEEN DONE
a) Token-Based Authentication and Source URL Filtering
In light of these resource limitations, I have implemented a short-lived token-based authentication system for my web clients. This approach restricts client interactions to a specific API endpoint, thereby enabling control and monitoring of client requests. Additionally, I employ source URL filtering to validate incoming requests based on their origin.
b) Identity Access Management Systems
In my pursuit of a robust security solution, I have explored Identity and Access Management systems as a potential avenue. Among the options I've considered, Keycloak has emerged as a promising solution. However, I've encountered a recurring challenge within this context.
Keycloak, like other IAM systems, requires the inclusion of sensitive data within the application. For example, the initialization of Keycloak necessitates the provision of configuration details, as illustrated below:
import Keycloak from 'keycloak-js';
const keycloak = new Keycloak({
url: 'http://keycloak-server${kc_base_path}',
realm: 'myrealm',
clientId: 'myapp'
});
try {
const authenticated = await keycloak.init();
console.log(`User is ${authenticated ? 'authenticated' : 'not authenticated'}`);
} catch (error) {
console.error('Failed to initialize adapter:', error);
}
You'll find all you need about it in the documentation
This situation has presented me with a recurring conundrum, as I find myself in a somewhat circular dilemma. While IAM systems like Keycloak offer security enhancements, they also necessitate the inclusion of sensitive data within the application code, which, in turn, introduces security concerns.
III) PROBLEMS AND LIMITATIONS ENCOUNTERED
a) Lack of Resources for Enhanced DDoS Security
In the context of mitigating DDoS attacks, I have encountered resource limitations, such as the absence of cloud-based infrastructure, which restrict my ability to implement certain security measures. Specifically, the option to clone the API multiple times as a means of distributing traffic and reducing the impact of DDoS attacks is not currently feasible due to resource constraints.
b) Vulnerabilities with Source Domain Name Filtering
However, it's crucial to acknowledge that this approach is not without vulnerabilities. The primary concern is that it relies on the source Domain Name as a means of filtering requests. While this method can be effective in normal circumstances, it remains susceptible to a specific type of threat.
c) Vulnerability Scenario
The vulnerability lies in the fact that an adversary, with the intent to compromise the system, could potentially create a counterfeit server that mimics my clients front end by using an identical Domain Name. In doing so, they could craft and send requests that mimic legitimate client interactions. The absence of a robust authentication process, combined with the reliance on source URL filtering, creates an opening for exploitation.
I would welcome further discussions with individuals who are interested in this topic. Together, we may explore potential solutions that align with the specific challenges I am facing.
Thank you for your time
Threat Model
If I'm reading the question correctly, the majority of your threat model concerns abuse of the trust between the application front-end and the API. Some examples of these threats include spoofing attacks, man-in-the-middle attacks, and replay attacks.
Potential Solution
If my interpretation is correct, then I suggest you look into mutual TLS (mTLS) as a potential solution for your threat model.
How It Works
Normally in TLS, the server has a TLS certificate and a public/private key pair, while the client does not. So the typical TLS process works like this:
But TLS also offers client-to-server authentication using client-side X.509 authentication. Both the client (in this case the app's front-end server) and server (in this case the API server) have a certificate, and both sides authenticate using their public/private key pair. Compared to regular TLS, there are additional steps in mTLS to verify both parties (additional steps in bold):
How It Prevents Threats
Mutual authentication can prevent spoofing attacks because the server will authenticate the client as well, and verify that it has the correct session key before allowing any further communication and access.
Mutual authentication can prevent MITM attacks because both the sender and recipient verify each other before sending their message keys.So if one of the parties is not verified to be who they claim they are, the session will end.
Mutual authentication can prevent replay attacks because timestamps are a verification factor that is used in the protocol. If the change in time is greater than the maximum allowed time delay, the session will be aborted. Also messages can include a randomly generated number to keep track of when a message was sent.