Member Avatar for anthonyjpv

Im building a simple yet robust small e commerce site

what i wanna know is:

is it more safe and secure to add the mysql commands such as select add update delete in the same html form

or create another php file for that as a process?

example:

i have an add customer page

the file is add.php

and for me to add that into the database

i pass variables and do the insert in another file called:

add_command.php

is it a big deal?

can the be a possible security issue incase?

thank you!

  • 3 Contributors
  • 4 Replies
  • 105 Views
  • 1 Day Discussion Span
  • Latest Post Latest Post by broj1

Dani AI

Generated

This thread is asking whether inserts/updates should live in the same PHP file as the form or in a separate processor (example: add.php vs add_command.php). Both patterns are used in real projects. Which is "safer" depends less on the filename and more on how input, database access, error handling, and deployment are implemented. The replies so far touch on visibility and separation; the practical gaps are server-side defenses, deployment hardening, and maintainability practices below.

Key security controls every e-commerce form needs (regardless of same-file vs separate processor):

  • Use parameterized queries / prepared statements to prevent SQL injection (see the PHP PDO docs and OWASP guidance).
  • Enforce server-side validation and output escaping; never trust client-side checks alone.
  • Protect POST actions with CSRF tokens and require HTTPS for all pages that handle credentials or PII (see OWASP CSRF cheat sheet).
  • Run the site with a DB user that has the least privileges necessary; store credentials in a config file outside the webroot and protect it with proper filesystem permissions.
  • Do not reveal raw DB errors to users; log them securely and show generic messages instead.

Practical architecture guidance: for a small site the single-file pattern (show form on GET, process on POST) is perfectly acceptable if the file includes a central bootstrap that performs CSRF checks, validation, and opens a secure DB connection. For maintainability and testing, a separate processor can make sense because it forces a single processing entry point and centralizes security checks. Either way, reuse a shared include for config, validation, and DB connection so security logic is not duplicated.

Minimal example (PDO, parameterized insert):

$stmt = $pdo->prepare("INSERT INTO customers (name,email) VALUES (?,?)");
$stmt->execute([$name, $email]);

Quick checklist before deployment: prepared statements, CSRF tokens, HTTPS, least-privilege DB user, config outside webroot, secure error logging, and a short security scan (e.g., OWASP ZAP). This set of practices will matter far more than whether SQL lives in the same PHP file or a separate one.

Resources: PHP PDO prepared statements, OWASP SQL Injection Prevention Cheat Sheet, OWASP CSRF Cheat Sheet.

Recommended Answers

All 4 Replies

Member Avatar for broj1

mysql commands are within php script and not in the plain html so it is safe to have them in the same script as the form. The commands are not (should not be) exposed to the browser.

Member Avatar for anthonyjpv

i mean the same php script where i put the form.

Member Avatar for TySkby

I would say it would be a concern.

Generally, you want to keep the front end as far away from the back (eg. your database) end as possible. Especially if it's for ecommerce where you could be handling some sensitive data on your site (but even just in general), I think keeping your front-end code for building forms and pages from touching your database is important.

Member Avatar for broj1

TySkby, what threats do you have in mind for cases where html form and mysql commands are in the same script?

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.