SQLPage turns SQL queries into web pages. That makes it useful for internal reporting and data entry, and it makes the definition of a protected page a database and application design question. A public SQLPage instance may show only a static page or it may expose a query that changes data.

On 9 November 2026 at 08:49 Asia/Shanghai, a ZoomEye query using sub_type=all, page 1, and page size 1 returned 64 assets for app="SQLPage". The title query returned 21 and the body query returned 109. The application fingerprint is the primary measurement because the product name is a better match than a generic body string.

The query is reproducible through the selected ZoomEye search.

Authentication can be local or delegated

SQLPage's documentation offers a built-in authentication component and SSO integration. The built-in path can manage users and passwords in the application, with helper functions for basic authentication and password hashing. The SSO path redirects requests to an identity provider and stores a signed token in an HTTP-only cookie.

Those are different trust models. Local passwords make the SQLPage administrator responsible for enrollment, reset, storage, and rate limiting. SSO moves authentication to the identity provider, but SQLPage still has to validate the token and map it to application permissions.

An authentication component on the login page is not the same as authorization on every component. The page that renders a table and the action that updates its rows need separate checks. Test the query endpoint directly, not only the UI route.

Page and action are distinct resources

A SQLPage application is assembled from components. A page may display a form, a table, or a chart, and an action may run a SQL statement. The protected resource is the action. If the server only checks authentication when rendering the page, a crafted request can still reach the action.

Build a role matrix for every action. A reader should be able to run the approved select query with fixed parameters. An editor may run an update that is constrained to a tenant or row. An administrator may manage users. The SQL statement should enforce the database role and the application should enforce the user role.

Use parameters rather than string concatenation. SQLPage's safety documentation describes safe defaults against SQL injection, but the application author still controls the SQL and the parameters. A dynamic sort column, table name, or filter expression needs an explicit allowlist.

The session cookie is a security boundary

The SSO documentation describes a signed HTTP-only cookie named sqlpage_auth. The signing key and cookie scope should be part of the deployment review. A cookie issued for one hostname should not be accepted by another origin. The application should reject an invalid or expired token rather than falling back to anonymous access for a protected action.

Test logout and session expiry. A user who signs out should lose access to protected pages and actions, not only see a different navigation menu. If the identity provider revokes a user, the application should have a defined maximum session lifetime and a plan for immediate revocation where the business requires it.

Practical checks for an owned instance

Use three accounts: anonymous, ordinary user, and administrator. Request a protected page and the underlying action directly. Change an object identifier, a tenant field, and a filter value. Confirm that the server returns an authorization failure rather than an empty page that hides the result.

Review the database role behind the SQLPage connection. The application may use one database user for every visitor. If that role can update tables, an action bug can become a data integrity problem. Separate read-only, write, and administrative roles where the component model allows it.

The 64 app matches are not a claim that every SQLPage deployment is public. They are an inventory signal for owned hosts. The review should connect the external page, the authentication method, the action authorization, and the database credential. SQLPage makes those relationships visible in SQL, but it does not make them safe by default.

References