The issue at hand may be common, but a solution has yet to be found. The website front.web.com has files that are accessed by the api.web.com. How can access to the api be restricted only to requests coming from the front.web.com domain? It seems difficult because headers can be forged and the key cannot be attached to the browser. However, the website dadata.com seems to use domain restriction to protect user tokens.

Correction: The website front.web.com has pages that use ajax to retrieve content from api.web.com. The proposed solution is to place an invisible google recaptcha 3 on all project pages, but its effectiveness in this situation is unknown.

Simply put, JSON and API are only available to authorized users. For other users, static content is collected entirely on the server side. Each API function request involves two API requests with an obfuscated JavaScript task executed on the client side between them.

The time limit between them is between 1 to 3 seconds. The first request involves signing the API request and receiving the JS task, while the second request entails getting a response to the API request. A temporary public token (PUB-TOKEN) is generated upon loading the page, based on HTTP protocol parameters. It is then exchanged through another request to the public key (API-KEY) using the JS code received from the API. This process takes place within 1-3 seconds, after which the API request is executed.

It is essential to ensure that all requests are unique, not reusable, and the JS task code generated is dynamic, unique, and difficult to analyze. The execution environment must be a real browser, and the task should execute quickly on the client side.

1) Can we use iptables to directly face the issue with the same IP?
2) Is api.web.ru equivalent to 127.0.0.1?
3) How can we use web servers like Apache to manage access (allow/deny)?
4) I am unsure if .htaccess supports the use of IP addresses with rewritemod.

signing requests through the API and verifying request senders.
This is done using a key, signature, and data. On the API side, we verify that the signed data matches. If it does, the user is granted access, but if not, they will be redirected elsewhere.

To restrict access to the API only from the front.web.com domain, you can employ various security measures. One common method is to implement Cross-Origin Resource Sharing (CORS) on the server hosting the API. With CORS, you can define which domains are allowed to make requests to the API.

By configuring the server to only accept requests with an "Origin" header matching front.web.com, you can effectively restrict access to the API. This prevents requests from other domains, even if the headers are forged.

Additionally, you can enforce secure communication by enabling HTTPS for both front.web.com and api.web.com. This ensures that requests between the front-end and the API are encrypted, reducing the risk of tampering and unauthorized access.

Regarding your mention of dadata.com using domain restriction to protect user tokens, it's worth noting that domain restriction alone may not be sufficient for complete security. It is important to implement multiple layers of security, such as token-based authentication and rate limiting, to further enhance the protection of user tokens.

As for implementing an invisible Google reCAPTCHA v3, it can provide an additional layer of defense against malicious bots. However, its effectiveness in this specific situation may vary, and it is recommended to evaluate the success of its implementation in deterring unauthorized access attempts.

Here are a few more security measures you can consider to enhance the protection and access control for your API:

1. Implement API keys: You can generate unique API keys for front.web.com and require them to be included in the headers of each request made to the API. This helps verify the authenticity and authorization of the requests. Keep the API keys confidential and rotate them periodically for added security.

2. Token-based authentication: Implementing a token-based authentication system, such as OAuth 2.0 or JSON Web Tokens (JWT), can provide an extra layer of security. Front.web.com can obtain and include a token in the requests to api.web.com, which is then validated on the API server to allow or deny access.

3. Rate limiting: Implement rate limiting to restrict the number of requests that can be made to the API within a specified time frame. This helps prevent abuse, brute-force attacks, and excessive usage that could degrade the performance of the API. You can set limits based on IP address or user identity.

4. Secure your server: Ensure that the server hosting the API is properly secured. Regularly apply security patches and updates, harden the server configuration, use secure protocols (TLS/SSL), and employ techniques like input validation, output encoding, and parameterized queries to prevent common vulnerabilities like injection attacks.

5. Logging and monitoring: Implement robust logging and monitoring mechanisms to track and analyze API requests and responses. Monitor for suspicious patterns, anomalies, and potential security breaches. This helps in identifying and mitigating any potential threats or unauthorized access attempts.