Member Avatar for 68thorby68

Hi,
I'm thinking of using the htaccess file on my apache server to add a layer of security to the payment processing on my site. I am considering the 2 actions below, not sure how yet, but thats where the trial & error & learning begins.

  1. rewrite the url for the files that do the processing i.e. the user completes the payment form at //mydomain/forms/form.php On submit the form data is posted to //mydomain/payment/form_process.php to process the payment - connect to the payment exchange, make payment, write to Db, etc, etc. I'm hoping I can rewite //mydomain/payment/form_process.php to something like //mydomain/blank: while the processing takes place, then show a useful domain name one the process redirects to the confirmation or error page.
  2. write a rule that blocks domains other than mydomain accessing //mydomin/payments/ folder, redirecting all attempts to access this folder to either 404 or index page.

Are the above possible, and if yes, will they significantly improve the security of payments on my site? Lastly, is there anything else I should consider when manipulating the .htaccess file for this type of processing?

Many thanks.

Edited by 68thorby68 because: important typo
  • 4 Contributors
  • 6 Replies
  • 337 Views
  • 9 Hours Discussion Span
  • Latest Post Latest Post by Member #46692

Dani AI

Generated

Short expert summary referencing the thread: ’s idea to rewrite the processing URL and block other domains with .htaccess is understandable, but it’s mainly security through obscurity as said. ’s suggestion to use .htaccess for hardening has merit for limiting casual snooping, and ’s point about offloading card storage to a provider is the strongest way to lower risk.

Concrete priorities (in order)

  • Ensure all payment pages and APIs use TLS (HTTPS) end-to-end.
  • Move gateway keys and credentials out of the web-accessible document root. Store them in protected config locations or environment variables, not in files under public_html.
  • Protect secrets with strict file permissions (owner-only read) and don’t commit them to VCS.
  • Make the processor endpoint strict: accept POST only, verify a server-side session/CSRF token, validate inputs server-side (prepared statements are already in place), and log/monitor failed attempts.
  • Consider hosted payment forms or tokenization (Stripe/PayPal/Braintree style) to avoid handling raw card data.

Small .htaccess / PHP patterns that help (not a replacement for secure design)

# Apache 2.4 — deny web access to a credentials file
<Files "gateway_config.php">
  Require all denied
</Files>
# Apache 2.2 compatible
<Files "gateway_config.php">
  Order allow,deny
  Deny from all
</Files>
# block non-POST requests to a processing endpoint (reduces accidental GET hits)
<IfModule mod_rewrite.c>
  RewriteEngine On
  RewriteCond %{REQUEST_URI} /payments/process.php$
  RewriteCond %{REQUEST_METHOD} !POST
  RewriteRule .* - [R=405,L]
</IfModule>

Final cautions and troubleshooting notes: Referer or host checks can be spoofed and IP-based blocks are brittle. .htaccess helps reduce surface area but won’t stop a compromised account or root access. For shared hosting where moving files outside webroot is impossible, prefer hosted payment pages or ask the host for secure environment variables/secret storage. If access is unexpectedly blocked, check Apache error and rewrite logs first.

Recommended Answers

All 6 Replies

Member Avatar for ryantroop

That's a bit of security through obscurity.

To what end are you planning on doing this?

Rewrites are good for looking professional. There is little security to it. It's basically a redirect. Even if I show you that you are posting to mysuperlockeddownphpscrupt.php you won't be able to do much to it if I code proactively (rejecting requests that don't originate from your server, making sure you sanitize data, prepare SQL, etc...). The only other way you can get burned besides SQL injection attacks that is within your control is to keep your passwords locked up and strong. If someone gets root access, all the .htaccess hackery in the world won't help you.

Member Avatar for veedeoo

pretty much there are few things you can do with .htaccess file. Please read #9 on this article. While you are at it, try reading some topics that are related to your situation.

Member Avatar for 68thorby68

Many thanks, you've probably saved me from hours, if not days, of trying to establish complex rules that wont achieve their objective. My code is pretty secure as I only use prepared scripts, I escape all form data, and impose pretty strict data parsing rules, i.e. I know what i'm expecting - email, telephone, alpha, numerics, string lengths and ao on, so therefore do not process anything that is out of the ordinary.

My real concern is protecting the payment gateway access codes which are held in a seperate files. I suppose I'd better read up on how to reject requests that don't originate from my server, maybe look some encrypting techniques and even ways of password protecting these files. Oh and i'd better make sure my hosting service have taken strict measures to prevent root access ?

Many thanks for your input and saving me lots of head scratching. Any advice on the above or a nudge in the right direction would be gratefully appreciated.

Again thank you for the sound advice.

Member Avatar for ryantroop

Fyi, you can spoof origination. It's only a stop gap. If you are worried about data, encrypt it. If you can't, let the big boys take care of it for you and use alternative methods. Most cc processors will allow everything from repeat billing to single small payments through their API, and they take care of everything you don't want any business with.

Member Avatar for 68thorby68

Many, many thanks for your advice.

Member Avatar for Member #46692

+1 for letting the big boys like paypal store those type of details.

Be a part of the DaniWeb community

We're a friendly, industry-focused community of developers, IT pros, digital marketers, and technology enthusiasts meeting, networking, learning, and sharing knowledge.