Welcome to Code Forum!

Join a community that supports you and your coding journey from day one. We strive to be a friendly, supportive community that empowers everyone to be better developers. By registering with us, you'll be able to discuss, share and private message with other members of our community.

SignUp Now!
  • Guest, before posting your code please take these rules into consideration:
    • It is required to use our BBCode feature to display your code. While within the editor click < / > or >_ and place your code within the BB Code prompt. This helps others with finding a solution by making it easier to read and easier to copy.
    • You can also use markdown to share your code. When using markdown your code will be automatically converted to BBCode. For help with markdown check out the markdown guide.
    • Don't share a wall of code. All we want is the problem area, the code related to your issue.

    GIF shows where to locate </> in the thread and or post editor toolbar.
    To learn more about how to use our BBCode feature, review our "How to post your code into threads" here.

    Thank you, Code Forum.

How to restrict access to PHP scripts to only be called from a single web site on same server?

JosiahMaybe

Platinum Coder
I know $_SERVER['HTTP_REFERER'] should be like my web page.
I also would have dedicated IP and could check that address but can't someone have a duplicate or spoof that?

If it helps, I would be using shared hosting from Asurahosting.com, Unlimited Plus plan.
I have not made this site yet.

I am trying for only one HTML page, that page itself, and nothing else may call a PHP script, one would send products and one would confirm email address.
Anyway, is it possible to be certain that it is coming from same server and one HTML page only?
No way to call AJAX while visiting not as page and no spoofing reference from?
Could this work with any type of hosting?
X E.
 
Solution
If I start from client side Javascript and end with a download I think I am stuck with too exposed as a usee could look at like my Javascript and know how to download directly so sorry but this is pretty much useless unless I can do like local host file system only from like my web page or something.
X E.
Might wanna watch your step there bud... that's grey area you're walking on there with local system access. Due to security purposes, browsers will not allow you to access local data... that's RCE territory... tread with caution
I would have to call PHP somehow from that web page. Does that require over exposing like my PHP? Like do I need a web URL or a regular URL for PHP script to be called on a server?
X E.
 
I would have to call PHP somehow from that web page. Does that require over exposing like my PHP? Like do I need a web URL or a regular URL for PHP script to be called on a server?
X E.
That is up to you. You can create an api endpoint that you can call that will retrieve that data without exposing too much of the details
 
If I start from client side Javascript and end with a download I think I am stuck with too exposed as a usee could look at like my Javascript and know how to download directly so sorry but this is pretty much useless unless I can do like local host file system only from like my web page or something.
X E.
 
If I start from client side Javascript and end with a download I think I am stuck with too exposed as a usee could look at like my Javascript and know how to download directly so sorry but this is pretty much useless unless I can do like local host file system only from like my web page or something.
X E.
Might wanna watch your step there bud... that's grey area you're walking on there with local system access. Due to security purposes, browsers will not allow you to access local data... that's RCE territory... tread with caution
 
Solution

About Using $_SERVER['HTTP_REFERER'] for Security​


$_SERVER['HTTP_REFERER'] can be helpful in basic use cases to suggest where a request is coming from, but it should never be fully trusted for critical security decisions. That’s because the Referer header can be:


  • Spoofed easily by someone using tools like cURL, Postman, or a modified browser.
  • Blocked or stripped entirely by privacy-conscious browsers or browser extensions.
  • Inconsistent: Sometimes the referrer may not be sent at all, depending on browser settings, HTTPS redirects, or meta tag configurations.

So while you can use it to add an extra layer of validation, you should not rely on it as your only check for protecting sensitive scripts (like product submissions or email confirmation).

2. Shared Hosting & Server-Side Restrictions​


Since you’ll be using shared hosting (like Asura Hosting’s Unlimited Plus plan), you likely won’t have access to deep server configurations (e.g., firewall-level IP filtering or advanced reverse proxy setups). However, you can:


  • Use PHP session tokens to validate that requests are coming from a user who actually loaded your page.
  • Use CAPTCHAs or CSRF tokens to prevent automated submissions or spoofed requests.
  • Restrict access via htaccess rules, allowing only certain directories or referrers (but again, this is not foolproof).

You mentioned having a dedicated IP—which is helpful for branding and SSL setup, but not really a security barrier in shared hosting. Others can still spoof requests even if your IP is known.

3. Limiting Access to One HTML Page Only​


If you want a specific PHP script (like product submission or email confirmation) to be callable only from one HTML page, you have a few viable options:
  • CSRF tokens: Generate a secure token on the page, store it in the session, and require it for script access.
  • POST-only access: Ensure your PHP scripts don’t accept GET requests.
  • JavaScript verification: Run checks using JavaScript before submission, though this is only client-side and can be bypassed.
  • Session flags: Set a flag in the user’s session when they load your HTML page, and check for that flag in the PHP script.

These won’t make it impossible to spoof, but it raises the barrier enough that casual abusers are unlikely to succeed.

​

4. AJAX Requests & Spoofing Concerns​


AJAX requests can be called from anywhere, not just your own HTML page—so yes, they can be spoofed if your scripts are public and unprotected.


To guard against that:


  • Require valid session or CSRF tokens with each request.
  • Optionally validate the user agent or IP address, though those too can be spoofed.
  • Log and rate-limit suspicious behavior.

5. SEO Considerations​


Now about SEO—which is smart to think about early on.


If you’re designing your site with only one HTML page, keep in mind:
  • Search engines thrive on content depth. A single-page site might limit your SEO opportunities unless it's well-structured with semantic HTML, fast loading, and well-placed keywords.
  • If you’re planning to share links to that one page, make sure your metadata (title, meta description, Open Graph tags) is highly optimized for search and social previews.
  • Ensure that your scripts and AJAX endpoints are not crawlable or indexable. Use robots.txt or meta tags like &lt;meta name="robots" content="noindex"&gt; on script response pages.
  • If you're adding links to other platforms or forums, context matters—surrounding your links with relevant content increases trust and potential click-through (and reduces the chance of being marked as spam).

Final Thoughts​


It is technically possible to set up a system where your PHP scripts are mostly protected from unauthorized calls, but you can’t guarantee 100% certainty—especially not in shared hosting environments.
Still, by combining techniques like CSRF protection, session validation, and careful script structure, you can achieve a strong level of control. And from an SEO standpoint, if you’re putting effort into your domain and content—even for a one-pager—it’s still worth building links and context thoughtfully. Make sure your content gives real value so that the SEO benefits are natural and lasting.
 
Back
Top Bottom