Pagpapatunay ng data ng input sa mga mobile app — mga batayan, pamamaraan ng pag-check, at implementasyon

Ano ang pagpapatunay ng data ng input?

Ang pagpapatunay ng data ng input ay ang pag-check kung ang mga data na pumapasok sa aplikasyon mula sa gumagamit, panlabas na serbisyo, o iba pang bahagi ay tumutugma sa inaasahang mga pamantayan. Kasama sa mga pamantayang ito ang uri ng data (string, numero, petsa), format (email, URL, telepono), saklaw ng mga halaga (edad mula 18 hanggang 120), haba (password mula 8 hanggang 128 na karakter), at mga pinahihintulutang karakter (mga letrang Latin lamang, numero, gitling). Kung walang pagpapatunay, maaaring i-proseso ng aplikasyon ang mga data na magdudulot ng mga error sa pagpapatakbo, pagkasira ng data, o mga kahinaan sa seguridad.

Bakit kritikal na elemento ng seguridad ang pagpapatunay?

Ang kawalan ng pagpapatunay ng data ng input ay ang pangunahing dahilan ng mga kahinaan tulad ng SQL Injection, XSS, Command Injection, Path Traversal, at Buffer Overflow. Ayon sa MITRE CWE (2025), ang CWE-20 (Improper Input Validation) ay nasa pangalawang puwesto sa ranggo ng mga pinaka-mapanganib na error ng software. Ang pagpapatunay ay ang unang linya ng depensa sa modelong pang-seguridad na Defense in Depth: pinuputol nito ang mga maling data bago maabot ang iba pang bahagi ng sistema.

Pagpapatunay vs Sanitisasyon

Tinatanggihan ng pagpapatunay ang mga data na hindi tumutupad sa mga pamantayan. Binabago ng sanitisasyon (paglilinis) ang data sa pamamagitan ng pagtanggal o pag-escape ng mga mapanganib na bahagi. Halimbawa, sa pagpasok ng nilalamang HTML, maaaring i-check ng pagpapatunay ang haba ng teksto, samantalang ang sanitisasyon ay maaaring magtanggal ng mga script tag sa pamamagitan ng library na HTML Purifier o DOMPurify. Hindi pinapalitan ng sanitisasyon ang pagpapatunay: gumagana ang mga ito nang magkapares. Ang pagpapatunay ay patakaran na "pinapayagan/ipinagbabawal", ang sanitisasyon ay "nilinis bago gamitin".

Mga uri ng pagpapatunay ng data ng input

Inuuri ang pagpapatunay batay sa lalim ng pag-check. Ang pagpapatunay ng format ay ang pinakasimple at pinakamabilis, samantalang ang pagpapatunay na pang-negosyo ay ang pinakakomplikado at nakadepende sa konteksto. Dapat ilapat ang tatlong antas nang sunud-sunod: una ang format, pagkatapos ang semantika, pagkatapos ang lohika ng negosyo. Ang paglaktaw sa alinmang antas ay maaaring magdulot ng maling paggana ng sistema o mga kahinaan.

Pagpapatunay ng format

Pag-check ng uri ng data, sukat, format, at mga pinahihintulutang karakter. Ipinapatupad sa pamamagitan ng mga regular na ekspresyon, mga built-in na uri ng mga wika, at mga library ng pagpapatunay. Mga halimbawa: pag-check ng UUID (format 8-4-4-4-12 na hexadecimal na numero), pag-check ng numero ng telepono (numero lamang, + sa simula, 7 hanggang 15 karakter), pag-check ng buong bilang (halaga sa saklaw ng Integer.MIN_VALUE — Integer.MAX_VALUE). Ang pagpapatunay ng format ay ang minimum na kinakailangang antas para sa bawat kolum ng input.

Pagpapatunay na semantiko

Pag-check ng lohikal na katumpakan ng data sa konteksto ng domain. Halimbawa: ang petsa ng pagsisimula ay hindi mas huli kaysa sa petsa ng pagtatapos, ang edad ay nasa makatwirang saklaw para sa sistema, ang mga coordinate ay nasa lugar ng serbisyo. Ang pagpapatunay na semantiko ay nangangailangan ng pag-unawa sa konteksto ng negosyo at hindi maaaring isagawa batay lamang sa format. Halimbawa: ang kolum na "bilang ng mga tiket" ay maaaring pumasa sa check ng format (buong bilang, > 0), ngunit sa semantiko ay hindi maaaring lumampas sa bilang ng mga bakanteng upuan.

Pagpapatunay na pang-negosyo

Ang pinakakomplikadong antas — pag-check ng data kung sumusunod sa mga alituntunin ng negosyo ng aplikasyon. Mga halimbawa: hindi maaaring tanggalin ng gumagamit ang nag-iisang administrator, ang halaga ng order ay hindi lumalampas sa limitasyon ng kredito, ang produkto ay maaari lamang i-order kung ito ay may stock. Ang pagpapatunay na pang-negosyo ay kadalasang nangangailangan ng mga query sa database o mga panlabas na serbisyo at isinasagawa pagkatapos ng mga check na format at semantiko. Ang mga error sa pagpapatunay na pang-negosyo ay ang pinakakaraniwang dahilan ng kawalang-kasiyahan ng mga gumagamit.

Pagpapatunay sa kliyente at server

Ang pagpapatunay sa kliyente (sa browser o mobile app) ay kailangan para sa kaginhawahan ng gumagamit: agarang feedback nang hindi nagpapadala ng data sa server. Subalit, ang pagpapatunay sa server ay ang tanging maaasahan dahil ang code ng kliyente ay laging maaaring lampasan. Magpadala ng mga request sa pamamagitan ng mga tool ng developer, Postman, o proxy (Burp Suite) — at ang pagpapatunay sa kliyente ay hindi na gagana. Ayon sa PortSwigger Research (2025), higit sa 90% ng mga nasubok na web application ay umaasa lamang sa pagpapatunay sa kliyente para sa kahit isang kolum.

Alituntunin: kliyente — para sa UX, server — para sa seguridad

Maaaring i-disable ng pagpapatunay sa kliyente ang buton ng pagpapadala, i-highlight ang mga error, at magpakita ng mga pahiwatig. Ang pagpapatunay sa server ay ang mandatoryong pag-check ng bawat parameter, kahit na na-check na ito ng kliyente. Ang pag-uulit ng pagpapatunay sa parehong antas ay karaniwang gawain. Dapat i-check ng server ang data na parang wala ang kliyente. Ito ang nagtitiyak ng proteksyon laban sa mga binagong request, awtomatikong pag-atake, at mga mapanganib na kliyente.

Implementasyon ng pagpapatunay sa kliyente

Sa web — mga HTML5 attribute (required, pattern, min/max, type="email") at JavaScript. Sa mga mobile app — mga native na validator para sa mga kolum ng teksto (InputFilter sa Android, textField(:shouldChangeCharactersIn:) sa iOS). React Hook Form at Formik para sa React, Vuelidate para sa Vue, Angular Reactive Forms — mga sikat na library para sa pagpapatunay sa kliyente. Sinusuportahan nilang lahat ang mga custom na alituntunin at asinkronong pagpapatunay (pag-check ng pagiging natatangi ng login sa server).

// Halimbawa ng pagpapatunay sa server sa Express gamit ang Joi
const Joi = require('joi');

const userSchema = Joi.object({
    email: Joi.string()
        .email()
        .required()
        .max(255),
    age: Joi.number()
        .integer()
        .min(18)
        .max(120)
        .required(),
    password: Joi.string()
        .pattern(/^(?=.*[a-z])(?=.*[A-Z])(?=.*\d).{8,128}$/)
        .required()
});

app.post('/api/users', async (req, res) => {
    const { error, value } = userSchema.validate(req.body);
    if (error) {
        return res.status(400).json({
            error: error.details[0].message
        });
    }
    // value — mga na-check na at ligtas na data
    const user = await User.create(value);
    res.status(201).json(user);
});

Pagpapatunay sa mga mobile app

Ang mga mobile app ay may mga espesyal na kinakailangan para sa pagpapatunay ng data. Mas maliit ang screen — ang mga error ay dapat maikli, ang keyboard ay kontekstwal (numerical para sa pagpasok ng mga numero), at ang pag-check ay dapat asinkrono upang hindi ma-block ang UI. Ang mga native na platform ay nagbibigay ng mga built-in na mekanismo ng pagpapatunay na dapat gamitin bilang default. Ang Material Design Guidelines para sa Android at Human Interface Guidelines para sa iOS ay naglalaman ng mga detalyadong rekomendasyon tungkol sa pagpapakita ng mga error sa pagpapatunay.

Pagpapatunay sa Android (Jetpack Compose)

Nag-aalok ang Jetpack Compose ng deklaratibong paraan sa pagpapatunay sa pamamagitan ng pamamahala ng state. Bawat kolum ng input ay nakaugnay sa isang state (MutableState), at ang error ay kinukuwenta batay sa kasalukuyang halaga. Pinapasimple ng library na Compose Validator ang paggawa ng mga alituntunin: required, email, min/max length, pattern. Naa-activate ang pagpapatunay kapag nagbago ang teksto (onValueChange) o kapag sinubukang ipadala ang form. Inirerekomenda na ipakita ang error pagkatapos lamang ng unang pagpapadala o pagkatapos matapos ng gumagamit ang pag-input (debounce 300-500ms).

Pagpapatunay sa iOS (SwiftUI)

Walang built-in na mekanismo ang SwiftUI para sa pagpapatunay ng mga form, ngunit madali itong maipapatupad sa pamamagitan ng Combine at property wrappers. Gamitin ang @State para sa halaga ng kolum at isang computed property para sa error. Ang framework na ValidatedPropertyKit ay nagbibigay ng mga handa nang decorator: @Validated().email(), @Validated().range(18...120). Rekomendasyon ng iOS — gamitin ang mga uri ng keyboard (UIKeyboardType.emailAddress, .numberPad) at auto-capitalization upang mabawasan ang bilang ng mga error sa antas ng input.

Pagpapatunay sa Flutter

Nagbibigay ang Flutter ng klase na Form at TextFormField na may built-in na pagpapatunay sa pamamagitan ng validator callback. Bawat kolum ay nagbabalik ng error bilang string o null kung tama ang data. Pinapatakbo ng FormState.validate() ang pag-check ng lahat ng kolum ng form. Ang paketeng reactive_forms para sa mga komplikadong kaso: mga custom na validator, asinkronong pag-check, dinamikong mga alituntunin. Ang Flutter Web at ang mobile na bersyon ay gumagamit ng parehong API, na nagpapasimple sa pagpapanatili.

// Halimbawa ng pagpapatunay ng form sa Flutter
Form(
    key: _formKey,
    child: Column(
        children: [
            TextFormField(
                decoration: InputDecoration(labelText: 'Email'),
                validator: (value) {
                    if (value == null || value.isEmpty) {
                        return 'Email is required';
                    }
                    if (!RegExp(r'^[\w-\.]+@([\w-]+\.)+[\w-]{2,4}$')
                            .hasMatch(value)) {
                        return 'Enter a valid email';
                    }
                    return null;
                },
            ),
            ElevatedButton(
                onPressed: () {
                    if (_formKey.currentState!.validate()) {
                        // Process valid data
                    }
                },
                child: Text('Submit'),
            ),
        ],
    ),
)

Mga teknik at tool ng pagpapatunay

Ang mga modernong framework ay nagbibigay ng mga built-in na validator na sumasaklaw sa 80% ng mga pangangailangan. Ang natitirang 20% ay nangangailangan ng mga custom na alituntunin, mga regular na ekspresyon, o komposisyon ng mga umiiral. Ang pangunahing prinsipyo — ang pagpapatunay ay dapat deklaratibo upang madaling basahin, subukan, at panatilihin. Iwasan ang lohika ng pagpapatunay na nakakalat sa mga controller at screen — ilipat ito sa mga hiwalay na klase o skema.

Mga paraan ng White-list vs Black-list

Ang White-list (puting listahan) — tinutukoy mo kung anong data ang pinapayagan, lahat ng iba ay tinatanggihan. Ang Black-list — tinutukoy mo kung anong data ang ipinagbabawal, lahat ng iba ay pinapayagan. Ang White-list ay palaging mas maaasahan: alam mo nang eksakto kung anong data ang dadaan. Ang Black-list ay nangangailangan ng pag-anticipate sa lahat ng posibleng pag-atake, na imposible. Halimbawa: sa pag-check ng edad, gamitin ang white-list (mga numero mula 18 hanggang 120 lamang), hindi ang black-list (pagbabawal sa "0", "-1", "999999").

Mga regular na ekspresyon — kapangyarihan at panganib

Ang mga regular na ekspresyon ay isang epektibong tool para sa pagpapatunay ng format, ngunit maaari silang maging pinagmumulan ng mga pag-atakeng ReDoS (Regular Expression Denial of Service). Ang ilang pattern (halimbawa, (a+)+b) ay nagdudulot ng catastrophic backtracking sa mahahabang string, na lubos na nagpapabigat sa CPU ng server. Gumamit ng mga nasubok nang regex library at limitahan ang haba ng string bago ilapat ang regular na ekspresyon. Para sa mga komplikadong kaso (email, URL), gamitin ang mga built-in na parser ng mga wika, hindi ang sariling mga regular na ekspresyon.

Mga karaniwang pagkakamali sa pagpapatunay

Kahit ang mga may karanasang developer ay nagkakamali sa pagpapatupad ng pagpapatunay. Ang pinakakaraniwan: pagpapatunay lamang sa kliyente, mga alituntuning masyadong mahigpit (password "Must contain uppercase, lowercase, digit, special char, >= 12 chars, must not repeat characters"), mga mensaheng hindi nakapagbibigay-kaalaman ("Error: invalid input"), at pagbalewala sa mga edge case (mga puwang sa simula/dulo, mga karakter ng Unicode, mga walang laman na string). Ang bawat isa sa mga error na ito ay nagpapalala ng UX at maaaring magpababa ng konbersyon ng mga form.

• Pagpapatunay lamang sa kliyente — ang pinaka-mapanganib na error: anumang request ay maaaring pekein sa pamamagitan ng Postman o cURL
• Mga alituntuning masyadong mahigpit — nagtataboy sa mga gumagamit: inirerekomenda ng OWASP ang mga minimum na kinakailangan sa pagrehistro
• Pagbalewala sa Unicode — ang pag-check ng haba ng string sa bytes (hindi sa mga karakter) ay nakakasira ng Filipino, Chinese, emoji
• Mga error na hindi nakapagbibigay-kaalaman — "Invalid format" sa halip na "Email must contain @ symbol after local part"
• Pag-check ng walang laman na kolum — ang if (value) ay hindi nakikilala ang walang laman na string mula sa zero, false, o "0"

Ang pinakamahusay na gawi — isang sentralisadong sistema ng pagpapatunay na natatakpan ng mga unit test. Bawat alituntunin ay dapat subukan nang hiwalay: mga hangganang halaga, mga tamang data, mga karaniwang pag-atake (mga pagtatangkang SQLi, XSS-payloads, mga napakahabang string). Pinipigilan ng mga regression test para sa pagpapatunay ang aksidenteng paghina ng mga alituntunin sa panahon ng refactoring. Gumamit ng property-based testing (QuickCheck, fast-check) upang makabuo ng mga random na data at upang ma-check na ang pagpapatunay ay hindi bumabagsak nang may exception.